On Jun28, 11:34am, Álvaro Justen <alv...@justen.eng.br> wrote:
> On Sun, Jun 27, 2010 at 23:51, dlin <dlin...@gmail.com> wrote:
> > About the Q1, I know that web interface. But, I'm wonder why not
> > provide direct file edit? That's will let my version control system
> > easier to track and view the differences. And I can use my editor to
> > global replace.
>
> > About the Q2, if the sentences is similar, why not reduce them?
>
> > Q3: Sometimes, one English word mapping to difference meaning of
> > Chinese. How can I deal with this? For example, if 'eat' means 'eat'
> > and 'kill' in Chinese. Then, the translate table will be
> > {
> > 'eat_1' : 'eat',
> > 'eat_2' : 'kill'
> > }
>
> > But, in English view, it will appear eat_1, eat_2, how to solve this
> > problem?
>
> > Q4: Can I suggest sort the translation table in ignore case alpha
> > order? That's let me easier to translate similar sentences.
>
> > Q5: Is there any function to force display all possible T() words in
> > tranlation table?
>
> > Q6: If the words is not translated, could it display different color
> > to let us easier to modify it?
>
> Maybe we should provide the developer to use a very stable
> internationalization system, like python gettext[1].
> Other projects use it and I don't know why we don't: it is shipped
> with Python by default and people that wrote gettext have experience
> on this, so probably they asked all those (any many more) questions
> about i18n.
> With the gettext domains (examples: myapp.chinese1, myapp.chinese2)
> you can separate your translation strings and have different
> translations for the same string (in different domains).
>
> For your case specifically, you can use a very dirty hack:
> T('some_string') and T('some_string ') (with spaces). Probably the
> space in the second string will not affect you if you put it on HTML -
> so you have 2 strings and can translate it the way you want.
>
> [1]http://docs.python.org/library/gettext.html
>
> --
> Álvaro Justen - Turicas
> http://blog.justen.eng.br/
> 21 9898-0141
My several cents...
About Q1, I had exactly same thought as dlin's, every time when I diff
the applications/admin/languages/foo-bar.py via VCS and saw those
human-unfriendly \x12\x34 etc. Then I tried to solve the problem in
fundamental gluon/languages.py but ended up giving up, every time when
I failed to find another implementation to beat current gluon/
languages.py 's simplicity.
Current languages.py uses repr() to gracefully escape possible single
quotation mark, double quotation mark, line-feed, etc inside those
language messages, by:
fp.write('%s: %s,\n' % (repr(key), repr(contents[key])))
Those \x12\x34 thing is the side effect of expr(...), sad but true.
The language resource file is a python dict, therefore can be easily
read by a simple:
lang_text = fp.read()
return eval(lang_text)
On the contrary, gettext uses a complicate language file format, [1],
no wonder the python/lib/gettext.py has three times of size than
web2py/gluon/languages.py, no doubt the latter is easier to understand
and maintain.
Still hope someone smart can figure out another simple way without
using repr(...)
About Q2, those duplicate similar sentences are caused by carelessly
writing messages in T(...), IMHO. I even saw these:
'A new version of web2py is available: Version 1.79.1 (2010-06-05
19:48:42)\n'
'A new version of web2py is available: Version 1.79.2 (2010-06-08
22:45:26)\n'
We should avoid using any easy-changing sentence inside T(...).
Q3 is out of the scope of any i18n system, I think. The solution is
use longer string in your app to avoid various meaning, and always
translate in a context rather than just do word-to-word translating.
Q4: I guess dlin can try to change line 60 of gluon/languages.py from:
for key in sorted(contents):
to:
for key in sorted(contents, key=str.lower):
Q5 & Q6: Perhaps you can change admin's translate interface, and
Massimo will take your patch.
Regards,
Iceberg
