Re: [bug-libunistring] libunistring: translating long names

[Benno Schulenberg]

Hello Daiki,

On 2015-02-18 09:22, Daiki Ueno wrote:
> It would be nice if those strings are presented in user's native 
> language on client applications, but translating those in each 
> application would be too much effort.  I'm thinking if it is feasible
> to gettextize libunistring and distribute PO/MO files.

Feasible it will be.  But will it be useful?  As far as I know, gnulib
no longer contains any PO files: gnulib's strings just show up in every
package that incorporates it.  Is libunistring different?  Will it stay
a separate library?  And if so, does it mean that a calling application
has to set and reset the text domain in order to get the translations?
Or will the library itself take care of that?

> If possible, I'd like to use the Translation Project (Cc'ed the 
> coordinator, also a generated POT file is attached for reference).

Using the TP for this is fine.  But many of strings contained in the
sample POT file have already been translated elsewhere, for example
in gucharmap (https://l10n.gnome.org/module/gucharmap/) -- the PO
files there contain all the category names (in a less pleasant,
swapped form) and script and block names, just not the combining
and bidi classes nor the joining types.  So... there would be quite
a bit of duplication there.  But that's okay: I can tell translators
to first msgmerge against gucharmap (or I can do it for them when
adding libunistring to the TP) before starting the translation.
Or maybe, now seeing this, you have a better idea?

One thing about the script names: quite a few of them in the sample
POT file contain an underscore -- for example "Imperial_Aramaic", 
"Old_Persian", "Meroitic_Hieroglyphs".  I think these underscores
should be converted to spaces.

Regards,

Benno