[Localization] [sugar] [Proposal] .xot bundles for translations

[Alexander Dupuy]

Martin Langhoff wrote:
> Using rpm or apt Sugar would getting a bit further away from Windows
> (does cygwin carry either?) - a bit less so on OSX (where the fink
> toolchain will probably work alright, specially with translation pkgs,
> which are by definition "noarch").
>   

I don't think that this necessarily prevents the possibility of OSX 
support via fink, but it's worth remembering that translation packages 
are not 'by definition "noarch"' - if the packages contain compiled 
gettext .mo files, those files may be machine-specific.  As noted in 
http://www.gnu.org/software/autoconf/manual/gettext/MO-Files.html

> The first two words serve the identification of the file. The magic 
> number will always signal GNU MO files. The number is stored in the 
> byte order of the generating machine, so the magic number really is 
> two numbers: |0x950412de| and |0xde120495|. 
> The |msgfmt| program has an option selecting the alignment for MO file 
> strings. With this option, each string is separately aligned so it 
> starts at an offset which is a multiple of the alignment value. On 
> some RISC machines, a correct alignment will speed things up.

In practice, it seems that the GNU gettext utils will support either 
endianness, and generate little-endian .mo files regardless of host 
byte-order (the discussion thread at 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468209 is informative 
here) so that you can get away with treating .mo files as noarch, but 
you might not want to do so in some cases (notably, for the discussion 
in that bug report, on slow-CPU (e.g. embedded) big-endian devices).

If for some reason you were wanting to support non-GNU libc based 
operating systems (like Solaris, which I realize is pretty irrelevant in 
this context) their gettext() implementation does not support automatic 
conversion of .mo files, and therefore packages containing them would 
not be architecture independent.

@alex

-- 
mailto:alex.dupuy at mac.com