Hi Grant,
See comments inline.
Grant Baillie wrote:
Hi, Brian
Thanks for the clarifications. A rephrasing of one of my questions is
inline below.
--Grant
On Jul 15, 2005, at 5:57 , Brian Kirsch wrote:
...
Are we going to output # c-format (or something similar) in .pot
files? In projects I've worked on in the past, inconsistent
translated format strings have caused a lot of grief (unexpected
raises, or crashes in C), and it would be good to be able to avoid
this.
Since we are using the Python gettext api the #c-format should not
come in to play. Python gettext does not put any #c-format comments
in .pot files. I can not think of a need for theses macro's at this
time. Do you?
I did, until I read your answer to the next question!
Lastly, because I'm a gettext newbie: Many translations require
some context (e.g. in the case of formatted strings, what the
arguments are). Is the gettext approach that translators figure
that out from the source file? (Ours was more that you'd add a
comment in the equivalent of the .pot file).
We are going to be using the PyICU MessageFormat syntax and
MessageFormat class for translations. As such the syntax is pretty
explicit on the types for each argument.
Ah, cool.
MessageFormat.formatMessage( _("At {1,time} on {1,date}, there was
{2} on planet{0,number,integer}."), args)
So the .po would contain:
msgid "At {1,time} on {1,date}, there was {2} on planet
{0,number,integer}"
I guess my question from before, is now: what tools/scripts are
available to help ensure that translations of (Py)ICU message format
strings are consistent? Otherwise, typos in translation can lead to
unfortunate behaviour (like unexpected raises).
Yes, enforcement and validation tools are going to play a large role in
our internationalization strategy. For .6 theses tools will not be
employed. But in .7 and beyond it will be a large focus.
For the MessageFormat a consistency checker needs to be written to
confirm that the abstract structure of the message (number/type of
parameters) has not changed between the original and any translations.
I am adding more detail on enforcement and validation to the .6 and
Internationalization Proposal.
Thanks for the feedback,
Brian
--Grant
--
Brian Kirsch - Email Framework Engineer
Open Source Applications Foundation
543 Howard St. 5th Floor
San Francisco, CA 94105
(415) 946-3056
http://www.osafoundation.org
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
