Re: English for msgids

[Robert Clausecker]

Hi Bruno,

Am Tue, Nov 28, 2023 at 07:02:40AM +0100 schrieb Bruno Haible:
> Robert Clausecker wrote:
> > There's lots of reasons not to use English for msgids:
> > 
> >  - the developer base may not mainly be English speaking and may have 
> > trouble
> >    coming up with grammatically correct English msgids
> 
> True. I've seen one or two programs from Japanese developers having these 
> problem.
> IMO, they could have their msgids revisited by a translator for 
> Japanese/English.
> 
> >  - a program that was originally written with messages in another language 
> > is
> >    internationalised by insertion of gettext() in the appropriate places
> 
> That's what I did initially in GNU clisp. But then realized that I wouldn't 
> get
> translators e.g. for Russian this way, and so I switched this package to 
> English
> as the primary language.

Sure, you can later switch to English msgids.  But being able to do a 
quick'n'dirty
i18n retrofit is a very valuable thing on its own, if only as a stepping stone 
to
English msgids.  And for that you need to be able to put arbitrary characters 
into
the msgid.  But if you're not able to do so, you'll have to translate 
everything to
English and write an initial message catalogue back to the original language 
(so you
don't lose the original strings) just to put i18n in.  That's quite a lot more 
work
just to get to a point where you can start to localise.

Or as they say, sometimes you gotta make a mess first so you can clean things 
up.
But if you can't make a mess, it may be much harder to get to the desired 
outcome.
So even use cases that may not be 100% ideal and could be done better should 
still
be supported, if only so you can evolve towards the desired outcome.

> >  - English has very sparse grammar and is almost isolating.  It often 
> > happens
> >    that an English msgid is translated in a contextually incorrect manner 
> > as the
> >    target language distinguishes some grammatical features that English 
> > does not.
> 
> True. As a mitigation, GNU gettext offers the so-called "translator comments" 
> in
> the source code. And we publish the email addresses of the translation teams, 
> so
> that users can report translation bugs.
> 
> Do you know other / alternative mitigations? Feel free to explain them.

I think the manual already gives very good advice for how to deal with that 
(write
msgids in full sentences, add provisions for numerus, put the interpolation 
into the
msgid instead of printing in steps, ...).  Yet it's not foolproof and we end up
with fun things like gedit translating syntax highlighting for Go into "Los" 
when
a German locale is selected.

On another note, I would like to get back to msgfmt() now transcoding the msgids
into Unicode.  Can you give me a scenario where this is the right course of 
action?
It's hard to imagine any case where you want anything but a byte-by-byte exact
match of the msgid.

And while you said that gettext() was not specified to transcode the msgid to 
the
current locale on lookup failure, what speaks against amending the interface to 
do
so?  After all, you seem to already be fine with minor compatibility breaks like
this.  And I think that would be something that should work for most 
applications.

Yours,
Robert Clausecker

-- 
()  ascii ribbon campaign - for an encoding-agnostic world
/\  - against html email  - against proprietary attachments