In the future can you please cc the Chandler developer list
([EMAIL PROTECTED]) .
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
