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

Reply via email to