Yay! It's spring, when young men's fancies turn lightly to thoughts of ... gettext:
http://www.abisource.com/mailinglists/abiword-dev/01/March/0454.html http://www.abisource.com/mailinglists/abiword-dev/01/April/1040.html I'd like to point out three related goals here. 1. let's make life easier for translators ------------------------------------------ There are a lot of willing translators in the Unix world, and switching to gettext would make them a lot happier. We currently have tools to convert back and forth between their PO files and our strings files, but I can understand why even that hiccup is annoying. >From what little I know of the PO format, it makes the work of maintaining translations easier for at least three reasons: - Unix translators are familiar with those tools - you can see the base string you're translating right there - you can tell when that base string changed underneath you It might not be hard for someone to write tools to provide equivalent functionality for comparing and versioning our XML-based strings files, but to date nobody has. Thus, it's pretty cool that Dom has volunteered to do the *non-Unix* work required to switch out the bottom layer of our lightweight strings mechanism in favor of gettext. ( I assume that the resulting resource files will be portable between platforms without having to worry about line-ending conventions, etc. ) http://www.abisource.com/mailinglists/abiword-dev/02/Apr/1124.html In return for that free gift, I personally am willing to forgo any of the possible technical quibbles that could be lodged against gettext: - locale bloat ... redundant storage of all those english strings - app bloat ... given that we already link an XML parser, the rest of the strings mechanism is almost certainly lighter weight than the gettext library - speed ... ID lookups should be faster than atomized string keys Given the performance of modern machines, I'm confident that none of these should be bad enough to offset the potential benefits to translators. Right? 2. let's make life easier for translators (non-Unix) ----------------------------------------------------- Could someone more familiar with gettext explain what a Windows user would need to do to create, say, a Swahili translation that our gettext-enabled builds could use on all platforms? I know there are more evolved PO-handling tools on Unix, but could they do the job -- and test the results -- without installing cygwin *or* a compiler? In an ideal world, that's how it'd work. 3. let's do the whole job -------------------------- More importantly, I'd love to see us do *all* the work required to completely remove locale-specific information from our static binaries. Ideally, we'd ship a hardwired en-US (yes, I'm a chauvinist, sorry) binary which could be easily packaged up with a collection of zero or more locale-specific resources. This has two advantages: - it reduces our core footprint - it allows after-the-fact translations to be "dropped in" To be clear. AFAICT switching to gettext does nothing to advance this goal. It merely switches the mechanism we use for the strings we've managed to externalize so far. Instead of shipping the current XML-based resources: abi/user/wp/strings/*.strings we'd ship the same information in a resource format that's prevalent on Unix systems. (See #1 above for a partial reason why that'd be useful.) As I've mentioned repeatedly in the past, the more serious problem is that we currently don't externalize enough of the locale-specific information. http://www.abisource.com/mailinglists/abiword-dev/01/March/0420.html Is anyone interested in coming up with solutions for the rest of the problem here? bottom line ----------- It's a good thing to make translators lives easier. Now we just need enough volunteers (for #2 and especially #3) so we can finish the job once and for all. Paul, lobbyist
