[Dev] Chandler Internationalization .6 Specification is ready for review

[Grant Baillie]

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).

--Grant