Re: Bug#451382: i18n is NOT so easy!

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Dec 9,  6:01pm, Peter Stephenson wrote:
} Subject: Re: Bug#451382: i18n is NOT so easy!
}
} This scheme has various merits: (i) it is robust about changes to
} the English text (ii) the explicit msgid serves as a visual cue that
} there's something here that shouldn't be monkeyed with without good
} reason (and that even if you change the English text it should mean
} the same thing) (iii) the msgid in the catalogues is compact.

This is close to the same scheme that I [*] adopted for localization
of zmail twelve years ago.  Except that we used a two-argument C
macro with the msgid and English text, rather than a delimited string.

We also had a number of tools that massaged the C source to add any new
msgid where a programmer had forgotten to use one, and to extract and
build the default English catalog file which could then be turned over
to translators.  It'd be pretty easy, I expect, to write a perl script
to find $"..." strings in shell scripts and extract them.

I'd be cautious about treating everything up to the first colon in a
$"..." string as a msgid key, though.  Error messages are going to
look like $"thing that failed: reason it failed" a lot of the time.  Or
would that have to be written "thing that failed: "$"reason it failed"
for this to work in the first place?  Anyway, it might be better to
adopt something like $"{msgid}original text" and treat both $"{message}"
and $"message" the same when only one of the two parts is found.

An additional issue that zsh may or may not have to address is that
you need entirely separate strings for things like plurals.  You can't
localize something like:

	There %s %d thing%s in the bucket

where the %s get replaced by "are" and "s" when the %d is not 1, and
"is" and "" otherwise.  You must instead have two strings (sometimes
three for the zero case):

	There are %d things in the bucket
	There is 1 thing in the bucket
	There is nothing in the bucket

There are gobs of other niggling details that I'm sure I've forgotten.

} However, it seems like we can get something better by interfacing to
} the library at a lower level, in particular to catopen() (strictly
} this is a different family of interfaces). That accepts an absolute
} path to a catalogue and also uses the environment variable NLSPATH to
} search for files.

This is also what I did back then in zmail -- gettext() didn't really
even exist yet at that point, at least not in a fully-developed form.
The POSIX cat*() interfaces work just fine, though NLSPATH searching
has some pretty nasty bugs on older operating systems.

[*] That's sort of the royal "I" as actually there was a whole team
of people working for me on it.

--