German (de-DE) not maintained

ranzwertig · June 12, 2013

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

horst · 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') ?

Soma · 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

ranzwertig · 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.

Soma · 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.

ranzwertig · 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.

Soma · 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.

Soma · 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.

ranzwertig · June 12, 2013

now I got it! thanks for you explanation!

horst · 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.

Manfred62 · 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

Nico Knoll · August 27, 2013

Just send it as a pull request to gitHub

Manfred62 · 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.)

Manfred62 · September 8, 2013

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

Soma · November 7, 2013

"Only required if..."

Is now translated as

"Nur benötigt wenn..."

That seems wrong as it should be

"Nur Pflichtfeld wenn..."

Manfred62 · November 11, 2013

@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

Manfred62 · 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.

Manfred62 · 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...

Manfred62 · 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

wayne · 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?

Manfred62 · 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.

wayne · 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.

Manfred62 · 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.

Torsten Baldes · May 12, 2014

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

Manfred62 · 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

Sign In

German (de-DE) not maintained

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Recently Browsing 0 members