ranzwertig Posted June 12, 2013 Share Posted June 12, 2013 @slkwrm thanks for the answer, mb_strtolower fixed it but still don't get why it works with different language settings. Link to comment Share on other sites More sharing options...
horst Posted June 12, 2013 Share Posted June 12, 2013 @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') ? Link to comment Share on other sites More sharing options...
Soma Posted June 12, 2013 Share Posted June 12, 2013 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 Link to comment Share on other sites More sharing options...
ranzwertig Posted June 12, 2013 Share Posted June 12, 2013 @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. Link to comment Share on other sites More sharing options...
Soma Posted June 12, 2013 Share Posted June 12, 2013 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. Link to comment Share on other sites More sharing options...
ranzwertig Posted June 12, 2013 Share Posted June 12, 2013 @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. Link to comment Share on other sites More sharing options...
Soma Posted June 12, 2013 Share Posted June 12, 2013 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. Link to comment Share on other sites More sharing options...
Soma Posted June 12, 2013 Share Posted June 12, 2013 @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. Link to comment Share on other sites More sharing options...
ranzwertig Posted June 12, 2013 Share Posted June 12, 2013 now I got it! thanks for you explanation! Link to comment Share on other sites More sharing options...
horst Posted June 12, 2013 Share Posted June 12, 2013 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. Link to comment Share on other sites More sharing options...
Manfred62 Posted August 26, 2013 Share Posted August 26, 2013 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 2 Link to comment Share on other sites More sharing options...
Nico Knoll Posted August 27, 2013 Author Share Posted August 27, 2013 Just send it as a pull request to gitHub Link to comment Share on other sites More sharing options...
Manfred62 Posted September 7, 2013 Share Posted September 7, 2013 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.) Link to comment Share on other sites More sharing options...
Manfred62 Posted September 8, 2013 Share Posted September 8, 2013 (edited) 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 September 9, 2013 by Manfred62 2 Link to comment Share on other sites More sharing options...
Soma Posted November 7, 2013 Share Posted November 7, 2013 "Only required if..." Is now translated as "Nur benötigt wenn..." That seems wrong as it should be "Nur Pflichtfeld wenn..." 2 Link to comment Share on other sites More sharing options...
Manfred62 Posted November 11, 2013 Share Posted November 11, 2013 (edited) @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 November 12, 2013 by Manfred62 Link to comment Share on other sites More sharing options...
Manfred62 Posted February 11, 2014 Share Posted February 11, 2014 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. 2 Link to comment Share on other sites More sharing options...
Manfred62 Posted February 12, 2014 Share Posted February 12, 2014 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... 4 Link to comment Share on other sites More sharing options...
Manfred62 Posted March 29, 2014 Share Posted March 29, 2014 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 Link to comment Share on other sites More sharing options...
wayne Posted March 29, 2014 Share Posted March 29, 2014 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? Link to comment Share on other sites More sharing options...
Manfred62 Posted March 29, 2014 Share Posted March 29, 2014 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. Link to comment Share on other sites More sharing options...
wayne Posted March 29, 2014 Share Posted March 29, 2014 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. 1 Link to comment Share on other sites More sharing options...
Manfred62 Posted March 30, 2014 Share Posted March 30, 2014 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. Link to comment Share on other sites More sharing options...
Torsten Baldes Posted May 12, 2014 Share Posted May 12, 2014 (edited) 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 May 12, 2014 by tobaco 1 Link to comment Share on other sites More sharing options...
Manfred62 Posted May 19, 2014 Share Posted May 19, 2014 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 1 Link to comment Share on other sites More sharing options...
Recommended Posts