Hello all, Guido Erlinger schrieb: > > (...) > > 2. Another thing I am thinking about is, if it is a good idea to > __store these translated texts in the database__ ... this is also > done for the description parameter!!!! > > I installed habari on my server with german language! I chose the > language at installation time! So the description of the tokens is > stored in german language in the database. If I now change the > langauge of habari in administration options, then these texts are > still shown in german, because the translation onyl works from > english to the chosen target language! >
In IRC Logs I found the following: > [14:21:24] <rick_c> > http://groups.google.com/group/habari-dev/browse_thread/thread/324c99c05e3e7a76 > > brings up a good point. Should translated strings > be stored in the database? Shouldn't translation > only occur on output to the browser? > [14:25:44] <mikelietz> I would think so. > [14:30:48] <rick_c> if that's the case, many of these are only > displayed by way of variables. how do we get them > into the translation file? > [14:39:28] <mikelietz> are these variables set somewhere? > [14:42:15] <rick_c> look at admin/group.php for an example. it > loops through the acl tokens to display them. > [14:45:17] <mikelietz> well, how much should we localize? > Is it too bad to always have 'admin' as a group name/token? > [14:46:17] <rick_c> if you don't speak english, i'd say so > [14:46:43] <rick_c> on display, that is. internally, they need > to be consistent > [14:47:35] <mikelietz> ok, so let's be anglocentric for a moment. > Say you can change the name of the admin group. > What happens when somebody comes in here with > token problems and we ask for them to check the > admin group tokens? > [14:47:51] <mikelietz> or will they just know to mentally > translate admin-> whatever? > [14:48:10] <mikelietz> I guess if they do that with everything else, > to ask questions here in english, it's no biggie. > [14:48:26] <rick_c> yeah > [14:48:45] <mikelietz> and agreed, internally, they need to be consistent. There are two points: ------------------------------ 1) Texts (like the descriptions of tokens), which should be translated somehow, and which are also stored in the database. If the site is onyl used in ONE language, it does not matter, if the text is stored localized like it happend for me, as I described it above. But for multilingual sites this is no option! My suggestion: Texts, which should be localized and which should also be stored in the database, hast to be stored in the database in English! rick asks, how to get these texts into the translation file. I see two ways: a) Create a dummy/void function like _v( "string to translate" ) which only returns the text, without doing anything. It is possible to configure poedit, to parse _v() keywords! This way you can get these text into the translation file. Hopefully launchpad.net can be configured the same way. b) The second possibility would be, to put the text in an comment like this: > self::create_token( 'manage_all_comments', 'Manage comments on all posts', > 'Administration' ); > // _t('Manage comments on all posts') I recognized that poedit does parses these too! But I do not like this way, because you have to write the text twice. And if the behaviour of poedit will be changed in future, this way would be broken ... also do not know if launchpad.net does parse gettext functions inside comments? ------------------------------ 2) The second point is how to handle the translation of texts, which should be consistent, independent from the chosen language, but localizable at output. I.e. these are the group names, post statuses, permissions (read, edit, deny, allow, ...) ... First I thought that these texts should be handled differently... These texts could be handled the same way, like described under 1). ------------------------------ My thoughts in summary: - Usind a dummy function like _v() to get the texts into the translation file. - it is only necessary to use _v(), when creating the tokens, groups, statuses, ... - at output time it is possible to use _n(), _ne(), _e() _t() with variables, because the text already should be in the translation file. ------------------------------ After writing all these lines, I recognized ONE PROBLEM: If the text in the source code will be changed in future times, the text in the database will not be changed! This means, that the localization will not work after an update, because the old text is still in the database, the translation file will contain the new text ... and because no translation is found, the english text from the database will be shown. ------------------------------ So ... what to do with this problem. At the moment I can not think of a smooth way out of this dilemma. I can see some workarounds ... but no way which I would prefer to use. Hope my thoughts will help, getting Habar forward for internationalization! regards, Guido -- Germany www.helpy.de --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
