Re: Updating PO files

[danilo gnome org (Danilo Šegan)]

Yesterday at 23:57, Shaun McCance wrote:

> Furthermore, translators can create or update their PO files with
> the very simple command 'make lang/lang.po' inside the document
> directory.  If I removed the $(_DOC_C_DOCS) dependancy, then they'd
> need a command like this:
>
> xml2po -e -u lang.po ../C/fe.xml ../C/fi.xml ../C/fo.xml ../C/fum.xml
>
> Making sure to get all the source files listed, and making sure to
> use our good friend -e.  That sounds like a recipe for disaster to me.

Or, they could grab *updated* PO file from

  http://kvota.net/doc-l10n/by-languages.html#sr

(#POT lists untranslated PO templates)

I'd even suggest this, because there are more advantages in doing it
this way: 
 - you don't have to ./configure your checkout (nor to have a complete
   checkout: help/C and help/<lang> should do)
 - you get nice diffs in very similar fuzzy messages
 - I plan to make fuzzy matching even better (eg. fuzzy matching by
   word, instead of by characters)

Of course, we need to move this to a better location.

> Alternatively, I could make gnome-doc-utils.make output a POTFILES file
> listing all the source documents.  It could be made only on request, or
> it could be added to all.  Then the translators could just do something
> like this:
>
> make POTFILES && xml2po -e -u lang/lang.po `cat POTFILES`

Anything involving "make" is going to "make THINGS_HARDER".
Translators usually don't have to ./configure packages to be able to
translate, so there would be no Makefile to start with.  I'll probably
write a simple shell script to run the mentioned xml2po command for
those not willing to use the stats page (or wanting to be faster than
the how regeneration works :) that will be as simple as:

  "doc-l10n-update sr"

run inside either where Makefile.am is (eg. "help") or where "sr.po"
is (eg. "help/sr").  It would read parameters from Makefile.am (that's
what the stats page is doing anyway).

> (Except I'm not sure if '-u lang/lang.po' is all right; there used to
> be problems doing it that way.)  Obviously, we could easily add stuff
> to xml2po to avoid the substitution thing as well.

I've added a day or so ago "--language"/"-l" option with which you
can set the translation language: this means that you should probably
use that to avoid breakages that might happen with parsing file name.


Now, on to xml2po expanding entities issue:
- current default xml2po behaviour regarding entities is to expand
  "inline" entities, and not expand "system external" entities (those
  referring to files): this is pretty hacky, since libxml2 python
  bindings don't actually provide me with this data;
  this was provided so we can have common case of "legal.xml" file
  included using entities translated separately—however, Shaun 
  taught me that this is what xinclude is for :)
- current default xml2po behaviour for g-d-u is to expand all entities
  (-e option)
- option -k (keep all entities) to xml2po is buggy at the moment

Now, since g-d-u is using -e, I'm probably going to drop default
behaviour (and the hacks it uses) as soon as I fix the "-k" option.
Would anyone mind that?

Cheers,
Danilo