[Po4a-devel] OS X .strings support

[Neil Williams]

On Sat, 3 Apr 2010 22:21:31 -0800
Aiet Kolkhi <aietkolkhi at gmail.com> wrote:

> >  * You want po4a to be able to extract the strings from a .strings and
> >   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
completely.

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 <-> PO
> > 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 for
> 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
gettext.

What is drawing you from .strings to PO? What problem are you trying to
fix?

> 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
seems pointless.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/po4a-devel/attachments/20100404/dc2749fb/attachment.pgp>