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

[Daiki Ueno]

Hi Benno,

Thanks for the comments.

Benno Schulenberg <address@hidden> writes:

> 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?

Yes, exactly.  I think it's not uncommon that applications call
bindtextdomain() multiple times and call dgettext() to retrieve
translations from different domains.

(Note that it doesn't mean gnulib or libunistring will call gettext(),
but a libunistring release will install libunistring.mo file.)

>> 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?

That was the motivation actually.  I didn't want to ask translators to
work on the same strings for a new character map:
https://l10n.gnome.org/module/gnome-characters/

> 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.

I agree that those strings shouldn't be presented as they are.  However,
they are from Unicode and it might make some sense to preserve the
original representation.  Maybe good to add translator comments and
include an English PO file for underscore conversion?

Regards,
--
Daiki Ueno