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
([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?
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
