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

[Jonas Beckman]

> 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? 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?


All the best,
Jonas