On Sat, 3 Apr 2010 22:21:31 -0800
Aiet Kolkhi <aietkolkhi(a)gmail.com> wrote:
> * You want po4a to be able to extract the strings from a
> generate a PO file, and be able to re-inject translations in the .strings
This is the functionality I had in mind.
po4a is more for extracting the strings from the original sources files
and then provide and update .po files for translation, creating the
final format with translations included - i.e. avoid .strings files
DocBook -> po4a -> PO -> translated groff
Normal gettext deals with runtime translation, using .po and .mo files.
.c -> .po -> .mo installed alongside the binary.
gettext already supports all common programming languages and does not
care about the underlying OS. Of course, how you mark up strings for
translation with .strings may differ from how gettext picks up strings
so a converter could make migration easier but I don't see a converter
as a long term solution. If .strings files are so hard to deal with
that you'd prefer PO, maybe it's best to make the jump to gettext in
the source code. Adding a converter is just going to add bugs.
> In both cases, I'm not sure po4a is suitable. A .strings
> converter would probably be much more useful.
I agree, this is a converter functionality basically. But then, I thought
one of the core features of po4a package was to ease localization on formats
other than PO by extracting strings from the source format and importing
them to PO (and then reexporting the translated strings).
To ease localisation of *source code formats* not usually handled by PO
files (typically documentation at this point) by extracting strings
from the original format (rather than another intermediary), importing
them to PO and converting the translations to the final content. The
source code for .strings is already well handled by gettext and PO
files - no need for po4a.
A .strings <-> PO converter would not need po4a at all - it would be a
frontend around gettext/intltool. IMHO it would be better to avoid the
initial .strings format and let gettext produce a PO file directly from
the source code (which it already understands). Once you've decided to
do that, you may as well adapt the source code to change the markup
to be suitable for gettext, add the code to get the translated strings
from the .mo files that gettext produces and the .strings format goes
away for ever. This could be as simple as defining a macro that changes
the meaning of the current string markup macro. (gettext packages
normally don't call gettext directly every time but define a macro like
_() or _g().)
In that case, the more formats po4a supports, the easier it will be
users to use po4a and not look for convertors elsewhere (and right now it is
very difficult to find and use .strings <> po converter).
If PO is so much better than .strings that a converter is desirable,
I'd say to dump .strings completely and get the source code to use
What is drawing you from .strings to PO? What problem are you trying to
But I may have misunderstood po4a concept.
Slightly, yes. You're looking for new runtime support. You're also
asking po4a to read a format other than the original source - which