Hello, On Sat, Apr 03, 2010 at 12:53:55AM -0800, aietkolkhi(a)gmail.com wrote: I do not know this format, so I don't know if there is a close enough format supported by po4a. Do you have links which describe the format? I also guess nobody is currently working in supporting the .strings format. Best Regards, -- Nekral

Hello, On Sat, Apr 03, 2010 at 02:41:40AM -0800, aietkolkhi(a)gmail.com wrote: OK, then .strings is yet another translation format as PO, XLIFF or .properties. po4a only supports PO files. You should first define what you would expect from po4a. The reasons I can imagine are: * You have a nice .strings editor, and you want po4a to generate and work with .strings files instead of PO files. * 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 In both cases, I'm not sure po4a is suitable. A .strings <-> PO converter would probably be much more useful. Best Regards, -- Nekral

On Sat, 3 Apr 2010 22:21:31 -0800 Aiet Kolkhi <aietkolkhi(a)gmail.com&gt; wrote: 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. 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().) 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? 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/