Moritz Lenz wrote:
However there are things that can be translated to other languages, and
that is documentation, error messages and warnings.
And the next step is non-error messages intended to be seen by users.
The latter two require that we standardize exception types and messages,
and provide some means to load different localizations.
If somebody could take on that project, that would be really great for
non-English speakers (and would also help the standard, English
implementation, because standardize exceptions make testing of
meaningful errors much easier).
That would be a real benefit for the Perl 6 landscape at large, and
probably not all too difficult (I'm sure that implementors of compilers
and STD.pm will help with technical details where necessary, I for one
would do my best to integrate such an effort into Rakudo).
I highly recommend a key-based approach, such that not even the English versions
of these error messages and warnings etc are in the program code, but rather are
in separate files, in the same format as versions of any other languages, and
that the only thing actually in the code is a non-human-language lookup key,
though that can be meaningful to programmers such as a variable name is.
See my simple Locale::KeyedText module for a working proof of concept of what I
speak of. Its the first module of mine that has matching Perl 5 and Perl 6
versions, and I had produced the Perl 6 version in 2005 as part of the early
Pugs development effort. This said, I haven't updated it in years and I don't
expect it to still run under Rakudo, but it did run under Pugs in the day.
The concept I describe and demonstrated is inspired by how Mac OS X works, where
all user text is in separate language resource files.
I also recommend against the older "gettext" (name?) design that involved having
one language's text inside the program code and using that as a key for others.
I prefer the more self-consistent design that I proposed.
-- Darren Duncan
