[Installit-dev] i18n string extraction

[Jannis Pohlmann]

Benedikt Meurer schrieb:
> Jannis Pohlmann wrote:
> 
>>Morning.
> 
> 
> Hey Jannis,
> 
> 
>>Benny, is there a common way you do extract the strings and stuff with
>>in other parts of Xfce? Something more automated than xgettext + msgfmt?
>>
>>I saw you store all po files and create the binary versions during the
>>build process. We don't have a build process but of course we could let
>>the user run some config/"build" scripts before he can use InstallIt,
>>right? Perhaps during the typical python setup.py install process.
> 
> 
> IIRC, gettext has good support for python, see
> 
>   http://docs.python.org/lib/module-gettext.html
> 
> So, why not just use gettext? It's easy to use and pretty much standard 
> (e.g. translators will already know how to translate .po files, etc.).

Yep, gettext is fine, it's just a mess to generate the .po files each
time (since it has to collect information from various files). I once
wrote a graphical solution for this for my employee (in Ruby). Let me
see if I can write a solution in bash which allows us to define all
files relevant for xgettext in just one file and generate the different
.po files using that. Ok?

> 
> My vision is that the new installer can still be a single file download. 
> E.g. a shell script, which includes a small tarfile with the python 
> scripts and the generated .mo files. No need to install anything (of 
> course there should also be an installable version, but that's an 
> option, not a requirement). Just double-click the downloaded script in 
> your favourite file manager, and the script untars the python source and 
> runs it, and cleans up after execution. That way upgrading is just 
> downloading the new file and deleting the old one. The generated gettext 
> .mo files and the python source (we could even ship python byte code 
> here, since it's platform independent, IIRC) should be small, so the 
> extraction overhead can be ignored. Does that conform with your current 
> plans?
> 

Sounds like a good idea. Anyway, I would still provide both: A
single-file-program and a distribution which is installed into the
user's system. We could write a little helper program to generate the
one-click-thingy for us so it won't be much effort for every release.
But I don't like to integrate this functionality into the core
sourcecode, I guess that's understandable.

Of course, this will require to ship binary formats (.mo instead of .po
and .pyc instead of .py) wherever possibly - not much of a problem, I think.

Regards,
Jannis