[Chandler-dev] Re: Script to upgrade localized PO files

[Brian Kirsch]

Hi Jonas,
See comment in-line.

Take care,
-Brian


On Aug 14, 2007, at 11:27 PM, Jonas Beckman wrote:

>
>> In the future can you please cc the Chandler developer list
>> (chandler-dev at osafoundation.org) .
>
> Certainly. Keeping relevant conversations online is always a good  
> idea.
>
>> Yes there are a number of po merging utilities freely available :)
>
> I know that now. :-) But few are both very simple and have complete  
> support for the file format (including easy access to comments and  
> inline-comments).
>
> And there is almost nothing with the express purpose of supporting  
> ongoing localization. All large localized applications have this  
> problem: getting someone to translate a bunch of strings once is  
> easy. But cleaning up localizations and keeping them in sync with  
> new versions takes more support (both from people and tools).
>
> Chandler is likely to remain a somewhat moving target for  
> localizers in the near future. So I am writng some scripts to make  
> the process easier for myself, in the hope that others will find  
> them useful.
>
>> 0.7.1 will be the first "Localizable" release. As such I plan to  
>> migrate all the work done in the
>> Chandler-en.po back in to the Chandler Python code. The 0.7.1  
>> Chandler-en.po will be
>> very minimal and include only a few string changes required after  
>> the 0.7.1 code freeze.
>
> That will be great! By the way, what kind of work can be migrated  
> back in to the code?

That is really just a fancy way of saying I will take all  msgstr  
strings in the Chandler-en.po
and make them the keys in Python code.

 From the Chandler-en.po
========================
#: Chandler.py:109
msgid "Another instance of Chandler currently has the repository open."
msgstr "Another Chandler is already running off the same data  
repository."


So for example, I would edit line 109 of Chandler.py and change the  
code to read

_(u"Another Chandler is already running off the same data repository.")

This will of course break some of the keys in the Chandler-sv.po which
is why we can work closely to ensure a smooth merge.


> I know you have already removed some strings for internal use.
>
>> Localizers will in 0.7.1, have the best / cleanest strings to work  
>> with in the Chandler.pot
>> template. Also we plan on adding localizer level comments to the  
>> Chandler.pot
>> so that many of the context issues that came up in the EuroPython  
>> Sprint such as "Dashboard",
>> "Triage" etc will be explained to the Localizer in-line.
>> This should make the translation process much simpler than you  
>> experienced.
>
> Cleaner strings is the way to go!
>
> Writing really good localizer level comments will not be easy. But  
> in the end, I think it can be useful even to fairly experienced  
> Chandler users.
>
>>> I also have a question about the generation process: there are  
>>> many multi-line "msgid" strings full of newlines, tabs etc.  
>>> Clever parser code can deal with this most of the time - but is  
>>> all that stuff necessary?
>>>
>>> We are using these strings as keys, after all, and it can get ugly.
>
>> That does raise a known issue of how much formating to include in  
>> the msgid keys and how
>> much to push to the WxPython layout engine to handle.
>
> Yes, I know it's an old issue. In my opionion, it is a bad idea to  
> put any unnecessary formatting in msgid keys. Of course, it may be  
> difficult to avoid in some cases.
>
> Short term, we'll just have to deal with some unpleasant keys. But  
> long term, I hope we get better support for separating layout and  
> localizable strings - perhaps by pushing more to Wx.
>
>>> Lines like this breaks PO parsing and my upgrade script:
>>>
>>> msgid ""
>>> "Many variable %s(var) here"
>>> msgstr ""
>
>> Do look in to this. The Chandler.pot was generated using xgettext  
>> and reported no errors.
>> I guess I am not fully understanding whether this is an issue with  
>> the Chandler-en.po or with
>> the parsing utilities that you are using. I will look in to this  
>> further as well soon as we start on 0.7.1.
>
> Yes, let's return to this later. I certainly have no full  
> understanding, either.
>
> I could always resort to writing code that works. :-)
>
> But perhaps I shouldn't. Even if there is a problem with my parsing  
> setup the general question remains: how complex are msgid keys  
> supposed to be in the first place?
>

Since keys are the English text, they can be as complicated as  need  
be to capture the English context.
However, as mentioned above English centric formatting (excessive  
tabs, newlines) is not really
appropriate and should be avoided in translations when possible. I  
will be looking in to this further
in 0.7.1.



>
> All the best,
> Jonas