localization, translating, ... and ACL:create_token(...), ...
Guido Erlinger
I just commented the following to ticket #874
The translation of the parameters in the calls of ACL:create_token(
name, description, group, crud) are not handled identically
througout the code. In the svn code sometime the strings, which are
passed as group parameter, are translated with _t(...). For instance
the default tokens which are created in acl.php:
The tokens for content and comments are created like this:
>
> // content tokens
> self::create_token( 'own_posts', _t('Permissions on one\'s own posts'), _t('Content'), true );
> self::create_token( 'post_any', _t('Permissions to all posts'), _t('Content'), true );
> foreach ( Post::list_active_post_types() as $name => $posttype ) {
> self::create_token( 'post_' . Utils::slugify($name), _t('Permissions to posts of type "%s"', array($name) ), _t('Content'), true );
> }
>
> // comments tokens
> self::create_token( 'comment', 'Make comments on any post', _t('Comments') );
You can see _t('Content') and _t('Comments') !!!
other tokens are created like this:
>
> // super user token
> self::create_token( 'super_user', 'Permissions for super users', 'Super User' );
>
> // admin tokens
> self::create_token( 'manage_all_comments', _t('Manage comments on all posts'), 'Administration' );
> // ....
'Super User' and 'Administration' are not translated with _t() !!!
1. I do not understand the habari code as far that I can say, what
is the propper way to handle the group parameter and its translation.
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!
So! there is more to do, ...
The Milestone where the translations should be fixed is given as
0.9. But I think that this should be done as soon as possible,
because there is more to do than only changing the "hardcoded
strings" ... and using the gettext functions.
There is another thing which is very HARD to translate. In the
source code there are some sentences which are put together from
serverel parts ... all these parts are passed to the gettext
functions separately.
This as very hard to translate. For instance if there is the string
"%s comments" ... this would be in german the "%s Kommentare"!
But on one place this text is put together with other parts and the
word _t(' with ') (german " mit "). In this special case in german
you have to use the dative! This means the result of "%s comments"
has to be translated with "%s Kommentaren" in order to get the
accurate case "... mit x Kommentaren".
On the other Hand all same english texts are always translated the
same way, because there is only one translation for it in the
language catalog. If "%s Kommentare" is used serveral times in
different contents it maybe should translated in different cases.
My suggestion: Whole sentences never should put together from
several parts, which are translated separately. If this is not
possible, the information sould be output as a list or as a table,
where normally the nominative case is used.
Another thing in translating are some "words" which are used like
constants. For instance some statuses like "published", "scheduled",
"draft" ... and sometimes theses constants are used to create
output. But this never should be translated, because they are
constants ... but in this case these constants also never should be
used for creating output!
There are more such text constants (i.e. "read", "edit", "delete",
"create", "deny", "allow", "deny", ...).
These constants never should be used to create output. But currently
they are used for creating output!
What could be solution? Maybe there should be an localized version
for each constant. ... or something like an display name! But the
translations (localized names) should never be stored in the
database, because if the language of the site is switched these
texts will not be translated again (see my example above)!
Hopefully you understand my english! Sometimes I use wrong
vocabulary or wrong tenses.
And hopefully these suggestions are helpful to you.
greetings from Bavari in Germany,
cu, guido
(helpy)
Guido Erlinger
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