[Chandler-dev] Re: Script to add accelerator keys

[Brian Kirsch]

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