On Sun, Jun 27, 2010 at 23:51, dlin <[email protected]> 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
