Jump to content
Nico Knoll

German (de-DE) not maintained

Recommended Posts

@slkwrm thanks for the answer, mb_strtolower fixed it :) but still don't get why it works with different language settings.

Share this post


Link to post
Share on other sites

@slkwrm BigThumbUp! ^-^
 
@ranzwertig When switching the userlanguage, it is done with setlocale. Especially here: LC_CTYPE for character classification and conversion.

But I don't know what PHP uses for a character type for the de_DE that it does conflict with UTF-8.

I'm not shure, but maybe if one haven't enabled mb_str-functions, if it also could be done with str_tolower(utf8_decode($text))?
please, can you try it once?

And what is the difference between setlocale LC_CTYPE and ini_set('default_charset','utf-8') ?

Share this post


Link to post
Share on other sites

Ah, now I see you used strtolower(string) which isn't multibyte compatible and since in utf8 cyrillic chars are multibytes it doesn't work correct. It's a string manipulation in PHP and if you have special chars like "üäö" the returned string will get screwed. There quite a lot of string function that do this, and it's normal and expected behavior and there's nothing wrong. So as slkwrm suggested you have to use mb_strtolower(string).

I'm not sure I understand what you mean with logged in vs logged out, because that doesn't make a difference. 

Edit: in fact you'll see the mb_ version of string function used all over in PW core if it's supported. For example https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/Sanitizer.php#L42

Share this post


Link to post
Share on other sites

@soma but thats exactly what I dont't understand. Whenever I am logged out the "äöü" with strtolower are fine. If I am logged in with a user using default language "äüö" is displayed properly too. But for german users logged in it is broken. So it's not a logged in / logged out problem its a language problem.

I will try the suggestions of @horst maybe I can find out what causes this.

Share this post


Link to post
Share on other sites

What I still don't get ( and I couldn't login on your site) is you're speaking of admin or front-end when you say it works/not works? Also do you use language fields or what setup do you have, because I see no language on your site. I can't reproduce this, nor have I experienced this when working with languages in PW.

Share this post


Link to post
Share on other sites

@Soma, I already removed the login. Whenever I have a user logged in with german language The Umlaute work in the backend. So alle umlaute are displayed properly there. In the templates they dont work if they are for example in the title field. If they are in the html they are fine too. I think they work in the admin because there is no strtolower and if there is this function mb_strtolower is used. For me now everything is fine since I am using mb_strtolower now. Using strtolowed it didn't work for logged in user with german language settings. So the problem is not urgent any more I was just wondering if there is some encoding/decoding happens with different languages.

Share this post


Link to post
Share on other sites

I can now see what you mean and it has to do with the setlocale. For german you have this set to de_DE, and in the default (if it's english) either you have entered en_EN or C (default), and it seems this has an effect on multibyte chars and string functions in PHP. http://stackoverflow.com/questions/5231620/what-does-set-localelc-ctype-c-actually-do around this issue. But since you're using different languages I don't see an issue using mb_'s in your templates. 

Share this post


Link to post
Share on other sites

@slkwrm BigThumbUp! ^-^

@ranzwertig When switching the userlanguage, it is done with setlocale. Especially here: LC_CTYPE for character classification and conversion.

But I don't know what PHP uses for a character type for the de_DE that it does conflict with UTF-8.

I'm not shure, but maybe if one haven't enabled mb_str-functions, if it also could be done with str_tolower(utf8_decode($text))?

please, can you try it once?

And what is the difference between setlocale LC_CTYPE and ini_set('default_charset','utf-8') ?

PW set's the locale with 

if($locale != '0') setlocale(LC_ALL, $locale);  (LanguageSupport.module)

and not LC_CTYPE ?

ini_set("default_charset","uft-8") I think is used for header that is sent to browser, and you can also set it in htaccess.

Share this post


Link to post
Share on other sites

PW set's the locale with 

if($locale != '0') setlocale(LC_ALL, $locale);  (LanguageSupport.module)

and not LC_CTYPE ?

@Soma: yeah, thats right, but LC_ALL includes LC_CTYPE, and LC_CTYPE for character classification and conversion is responsible for use of str_tolower, strtoupper etc.

Share this post


Link to post
Share on other sites

small update to the german laguage pack. In the zip are following new files:

  • wire--core--pages-php.json
  • wire--core--wirehttp-php.json
  • wire--core--wireupload-php.json
  • wire--modules--fieldtype--fieldtypecomments--commentfilterakismet-module.json
  • wire--modules--fieldtype--fieldtypecomments--fieldtypecomments-module.json
  • wire--modules--fieldtype--fieldtypecomments--inputfieldcommentsadmin-module.json
  • wire--modules--languagesupport--languagesupportfields-module.json
  • wire--modules--languagesupport--languagesupportpagenames-module.json

I took them from Radek's cz files and translated them. Maybe someone (yellowled?) can check/correct them before loading up to GitHub?

Some phrases are ... difficult to translate.

de-DE.zip

  • Like 2

Share this post


Link to post
Share on other sites

just try to find some missing strings in the translation (for the dev version). One example:

in \wire\modules\LanguageSupport\ProcessLanguage.module there are 2 translation strings for title and summary missing:

class ProcessLanguage extends ProcessPageType {

        static public function getModuleInfo() {
                return array(
                        'title' => __('Languages', __FILE__),
                        'summary' => __('Manage system languages', __FILE__),
                        'version' => 100,
			'author' => 'Ryan Cramer',
			'requires' => 'LanguageSupport',
                        );
        }

now the /setup/ is full translated. After that you have to rename the Languages page in the tree under Admin/Setup to get the heading and breadcrumb translated. Correct? Or should this be done better via translation strings?

EDIT: that's not the correct way. Seems, there are missing translation strings in the language modules? Where?

in general:

  • where can I post missing things like this (which is in the core)? Is it welcome? Unnecessary?
  • it is hard to find all translatable strings and translate them. There should be a simple overview (new strings in bla.module, blubb.module renamed, bang.module deleted etc.)

Share this post


Link to post
Share on other sites

short update:

EDIT: that's not the correct way. Seems, there are missing translation strings in the language modules? Where?

the missing string has to be placed in /wire/templates-admin/default.php. Maybe could be done with installation process of the language support module?

/*
 * Dynamic phrases that we want to be automatically translated
 *
 * These are in a comment so that they register with the parser, in place of the dynamic __() function calls with page titles. 
 * 
 * __("Pages"); 
 * __("Setup"); 
 * __("Modules"); 
 * __("Access"); 
 * __("Admin"); 
 * __("Languages");  // the missing phrase
 * 
 */

after that it's translatable.

Also have done some more translations for the german language pack (for 2.3.4). Will send a pull request soon.

Edited by Manfred62
  • Like 2

Share this post


Link to post
Share on other sites

"Only required if..."

Is now translated as 

"Nur benötigt wenn..."

That seems wrong as it should be

"Nur Pflichtfeld wenn..."

  • Like 2

Share this post


Link to post
Share on other sites

@Soma: where is this string?

EDIT: found and done (prepared locally)

I have some more translations prepared for the 2.4 version (on my local 2.3.6 installation), but will wait with pull-request until Ryan is ready.

Edited by Manfred62

Share this post


Link to post
Share on other sites

german translation for PW 2.4 is ready and waiting for pull-request.

In my case there's a problem with translation of /wire/templates-admin/ files. Not sure, what's the problem here.

Maybe it's only in my environment? But Ryan already has this on his to-do list.

  • Like 2

Share this post


Link to post
Share on other sites

until now we are not sure how to place module translations on github. Therefore you can download the first 3 here.

Zip contains the following module translations:

CKEditor

ModulesManager

Thumbnails

modules-de.zip

BTW: actual ModulesManager needs also a translatable JqueryDataTables.module to get the full de-gui...

  • Like 4

Share this post


Link to post
Share on other sites

while playing with the new PW dev version I updated some strings. If someone uses the dev in german already, here are 4 updated files:

ProcessPageEdit
ProcessPageAdd
ProcessModule
ProcessTemplate

pw-lang-de-dev-update.zip

Share this post


Link to post
Share on other sites

There is a quite important untranslated "field" for InputfieldDatetime.

It's basically a path to the language file for the jquery datepicker plugin.

/wire/modules/Jquery/JqueryUI/i18n/jquery.ui.datepicker-de.js

Could you add that to the language pack?

Share this post


Link to post
Share on other sites

There is a quite important untranslated "field" for InputfieldDatetime.

It's basically a path to the language file for the jquery datepicker plugin.

/wire/modules/Jquery/JqueryUI/i18n/jquery.ui.datepicker-de.js

Could you add that to the language pack?

thanks for the hint. I made a pull request on GitHub.

Share this post


Link to post
Share on other sites

Thanks, but it's not enough to set only the language code "de". You have to set the whole path:

/wire/modules/Jquery/JqueryUI/i18n/jquery.ui.datepicker-de.js

I fell into the same trap.

  • Like 1

Share this post


Link to post
Share on other sites

Thanks, but it's not enough to set only the language code "de". You have to set the whole path:

/wire/modules/Jquery/JqueryUI/i18n/jquery.ui.datepicker-de.js

I fell into the same trap.

oops, your'e right. Pull request done.

Share this post


Link to post
Share on other sites

argh, never mind!

i just switched my user role back to german/default and all is good.

i guess the files don't show up for the default language, but will still be used …


hi,

i tried to use this language pack for the default language, but i can't get it to work.

if i create a new language and upload the zip-file or the json-files everything works as expected.

but i want my primary language to be german and the second language english.

when i upload the file(s) in the default language, the language files are gone after saving the page and it defaults to english.

is this a known problem?

i'm using the latest dev-branch of processwire.

thanks!

Edited by tobaco
  • Like 1

Share this post


Link to post
Share on other sites

new german updates for actual PW dev 2.4.2 (19 May 2014). Zip contains only updated files.

inputfield-php.json
pages-php.json
fieldtypefile-module.json
fieldtypepage-module.json
inputfieldtinymce-module.json
processmodule-module.json
processpageadd-module.json
processtemplate-module.json

pw-lang-de-dev-update.zip

  • Like 1

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...