[Libreoffice] l10ntools clean-up?

[Stephan Bergmann]

Hi all,

Trying to make comphelper depend on officecfg (to be able to use the new 
simplified configmgr API in comphelper), this currently fails due to 
officecfg depending on translations, translations depending on 
l10ntools, and l10ntools in turn depending on tools (which is pretty 
high up in the hierarchy, and depends on comphelper in particular).

While there is probably not much that can be done about the first two 
dependencies in that chain (officecfg -> translations -> l10ntools), 
l10ntools depending on tools looks like a relic of the past.

While some of the tools from l10ntools are actually Perl/Python scripts 
(addkeyid2pot, fast_merge, keyidGen, po2lo, propex, propmerge), others 
are C++ programs (cfgex, gsicheck, helpex, localize_sl, transex3, ulfex, 
xrmex).

 From what it looks like, those C++ programs carry forward some 
stone-age code, and generally could use an overhaul.  For example, there 
is code that copies files around to temp files, only to strip a leading 
BOM before feeding into flex.  I think that can be drastically simplified.

Unless there's someone who screams "but all this should go away in the 
next couple months, anyway!" I would therefore go ahead and clean that 
code up, ridding it of any tools dependencies (should hopefully not be 
too difficult to base it either on sal or even on the plain C++ standard 
library).

An alternative might be to re-write those programs in Python (seeing 
that there is already one other Python script, po2lo; re-writing in Perl 
would *not* be an option, Perl not being a language to write programs in 
in the first place).  However, given the nature of those tools' work, 
regressions might be hard to spot, so I would like to keep modifications 
to the code in bounds.

What do people think?

Stephan