bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gettext MO format version numbers


From: Dwayne Bailey
Subject: Re: Gettext MO format version numbers
Date: Tue, 17 Feb 2009 08:47:37 +0200

Adding Friedel who might want to add something to this thread.  Friedel
this started as me asking for clarification on the different MO version
numbers.

On Mon, 2009-02-16 at 12:08 +0100, Bruno Haible wrote:
> Dwayne Bailey wrote:
> > > minor revision number is 1 (meaning that some strings have substrings
> > > whose expansion depends on the system type).
> > 
> > Could you maybe explain what this means?
> 
> Currently, the substrings with system dependent expansion can be
>   -  C 99 section 7.8.1 format string directives,
>   - the "I" flag for outdigits (only supported by glibc systems).
> See gettext/gettext-runtime/intl/loadmsgcat.c function 
> get_sysdep_segment_value
> for some details.
> 
> > > it is better to simply invoke 'msgfmt' and
> > > 'msgunfmt' when creating or reading MO files, respectively.
> > 
> > In some use cases I've needed to ignore using the commands directly.
> 
> Why? If there is some option missing in msgfmt or msgunfmt, you can tell me.

No no options missing, I'm pretty good at asking for those :)

It has been more an issue of not wanting our tools to depend or require
gettext tools e.g. on Windows where packaging can be hard.  Some reasons
are our evolution in that we still have our own PO parser although we
can use libgettextpo now for almost all things.

So these could be revisited.

> > Now if I could do reading and writing like I do with libgettextpo that
> > would help :)  But I guess that might be a lot of work for a single
> > user.
> 
> libgettextpo was created for the purpose of PO file editors (think of
> poedit). Currently I think you can do everything in this direction by
> manipulating PO files in memory (via libgettextpo) and invoking
> msgfmt/msgunfmt. But I certainly don't know your use case? Can you
> explain your use case?

Here are some:

1) With my mo class I can traverse a set of MO files
e.g. /usr/share/locale and am easily able to extract all messages and
put them into the users Translation Memory, I call it TM recovery.  The
same could be done with msgunfmt to a file then parsed by libgettextpo.
But that's pretty yuck compared to the ease with which I can do it now.

2) Direct editing of MO files.  With an MO handler we are able to open
MO files in Virtaal (our desktop PO editor) make changes and save,
without needing the clutter of intermediary PO files.  Yes it
potentially creates problems if you get out of sync, buts its a pretty
neat way to quickly verify and fix bugs.

3) Build MO files.  We have a tool called pocompile that is able to take
almost any of a bilingual stores and convert it to an MO file.  We could
do that same by doing an intermediary file but this, so far, has been
simpler for us.  Thus we are able to take a PO style XLIFF file and
convert it directly to MO.

4) Less important: Using 1) I've been able to check issues like
encodings and find broken MO files.  It still amazes me that we have
such things when we mostly have automated builds for MO files.  I also
am able to find encodings that are not present in Python but used in an
MO so that we can eliminate any potential issues there.

> > 1) Would be good to reference people to gmo.h if they need further
> > information.
> 
> It's well-known that for open-source software, if you want excruciating
> details, you need to look in the source :-)

And its also less know that a simple link to the source can save an
amazing amount of developer time ;) I can't remember but I think I
stumbled across libgettextpo!

> > 2) The page has an illustration of the structure of an MO file.  Your
> > diff doesn't add information about system type entries to that picture.
> 
> Yes, that diagram would become way too confusing if these system dependent
> substrings were included.
> 
> Bruno
-- 
Dwayne Bailey
Associate                                      +27 12 460 1095 (w)
Translate.org.za                               +27 83 443 7114 (c)

Recent blog posts:
* Fixes for Skype Video, Webcam on Fedora
http://www.translate.org.za/blogs/dwayne/en/content/fixes-skype-video-webcam-fedora
* libtranslate, TM plugins and Virtaal
* Localisation Information Language - preventing mistakes and increasing the 
richness of localisation

Stop Digital Apartheid! - http://www.digitalapartheid.com
Firefox web browser in Afrikaans - http://af.www.mozilla.com/af/
African Network for Localisation (ANLoc) - http://africanlocalisation.net/






reply via email to

[Prev in Thread] Current Thread [Next in Thread]