Well,
To address the context question I have been experimenting with the
xgettext c utility.
It has a feature which will also parse comments from code or comments
with a
specific keyword. I am going to start employing this strategy in 0.7.1.
So specifically one could add a comment such as :
# Triage is used to sort Chandler Items based
# on the statuses Now, Later, or Done ...
t = _("Triage")
The comments would end up in the po file ala:
#. Triage is used to sort Chandler Items based
#. on the statuses Now, Later, or Done ...
#: test.py:9
msgid "Triage"
msgstr ""
Using a tool like poEdit the translator
can view the comment in a UI while providing the localization.
The translator can also (via poEdit or manually) add a localizer comment
in the translated po file to correspond to the other comment etc.
One can also tag comments as an argument to xgettext so:
# This is a general programer commented that will not appear
# in the po.
# L10N: Triage is used to sort Chandler Items based
# on the whether it is Now, Later, or Done ...
t = _("Triage")
Only the L10N comments would be migrated to the po file.
Pretty cool huh?
I think this will solve our issue of providing context to Chandler
localizers.
Thanks,
-Brian
On Aug 1, 2007, at 11:20 AM, Jonas Beckman wrote:
I'm glad you like po_check and found it useful. We can certainly
find some way to get it into the code base.
The generated stuff itself may not be that useful for Chandler
developers, only for localizers. It's not an either or thing - the
script will leave whatever you enter by hand alone. So you could do
add exactly what you want first and just let the script fill in any
missing accelerators.
The general question I asked myself was: If more context is
necessary to do good localization... where do you find it? And
where should it go in the future? Building a few scripts built
around what currently exists at least makes it easier to ask the
questions.
I really think keeping tight control of the Chandler_en.po file is
a very good thing in general. But it also makes the PO file a more
likely place to add additional localizion metadata, even if the
file format is limited.
With a bit of luck I should be able to automate most - if not all -
of the PO merge soon. I looked at your changes today and will
certainly let you know.
You take care, too.
Jonas
Brian Kirsch wrote:
Cool,
Interesting stuff. I can't say to what extent the dynamically
generated accelerators
will be accepted by the OSAF development team however. We will
have to see.
Do let me know how the merge goes with the Swedish po. That will be
a very important use case in future Chandler releases.
By the way as part of the Chandler-en.po clean up, I used your
po_check script
along with the c version of msgfmt to confirm that the new po was
error free.
I really like po_check and we will certainly with your permission
incorporate
some version of it in to the Chandler code base post-Preview.
Take care,
Brian
On Aug 1, 2007, at 8:07 AM, Jonas Beckman wrote:
Hi Brian!
I'm glad to see your hard efforts to maintain the localization
freeze. And the new PO file is also very welcome. I think it will
be quite easy to merge with our current one.
In fact, I am working on a migration script and will get back to
you with some feedback (and hopefully a merged file) as soon as
possible. I was already working on something else when I saw your
post on Chandler-Dev, so the timing is good.
Remember my suggestion that accelerator keys could be auto-
generated? Well, I did some hacking and implemented that. My code
currently works only for menus defined in "...parcels/osaf/views/
main/menus.py". But it could easily be extended to cover other
parts of the GUI. Here is a session:
***
$ python po_accelerators.py -e -a chandler_sv.po -s
chandler_svnew_po
Finished extracting metadata
Found metadata for 24 menus
Reading translated strings from: ./
Analyzing accelerator keys. Please wait...
Added accelerator keys to 94 menu items
Saved new file with applied changes: './chandler_svnew.po'
***
-h will show help (and -v will display what it adds to the file).
Basically, I wrote two basic modules and added my little
accelerator hack on top of that. First, "localization_repo.py"
reads POT and PO files into memory and gives them a nicer API.
Just instantiate a LocalizationBrowser and ask it for numbered
lines, content of msgid strings or whatever.
Second, "gui_metadata.py" reads Chandler code and extracts GUI
hierachies (like menus and menu items). Turns out I didn't had to
add anything to the framework code. Still... parsing metadata
from code like this doesn't seem quite right: this is fragile and
app-specific code. But until you point me somewhere else that's
all I can do.
I have some unit tests and try to wrap away ugly stuff like
newlines or unicode boundaries. But the only documentation is in
the code, so far. Everything is checked in, so you can take a
look when you have time.
Oh... before you try to build a new egg, you should probably open
the generated PO file in a Unicode-aware editor and save it as
UTF-8. I will fix that, but haven't had the time to test om
multiple platforms yet.
OK, that's it for now. I'll get back about merging PO files.
Later,
Jonas
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
