i18n for gfortran-compiled code (or Fortran in general)

[Tobias Burnus]

  Dennis Wassel wrote:
> What I am thinking about is rather simple string localisation, limited
> to "non-extraordinary" languages in and around Europe and America, no
> LTR/RTL stuff, and no Asian glyphs. Think English, German, Spanish,
> Turkish, for instance.

In principle there should be no problem with Unicode (UCN-8)/UTF-8. 
Fortran 2003 supports this optionally and Fortran 2008 requires the 
support. (gfortran 4.4 has almost complete support for it, 4.6 completed 
it.) Cf. 
http://gcc.gnu.org/onlinedocs/gfortran/SELECTED_005fCHAR_005fKIND.html

> It is primarily supposed to cooperate peacefully with gfortran and the
> existing machinery under various platforms (linux, *nix, windoze,
> mac), and it would need to have a "switch off" feature in favour of a
> default English fallback. Non-too-fancy preprocessor tricks are
> acceptable, since all source files are preprocessed anyway.

I think at the end it boils down to replace
   string = "Hello World"
by
   string = my_i18n ("Hello World")
where "my_i18n" checks whether for the currently requested language a 
translation is available - and if not it simply returns the original string.

> * gettext is probably too C-centric for it to integrate peacefully,
> and it is GPL, so unacceptable for our code anyway.

gettext essentially works as written above for "my_i18n" except that the 
function call gets inserted via some CPP magic. The strings are 
extracted from the source files - and written into a .po(t) file; msgfmt 
translates it into a binary .mo which is then read at run time.

You could implement something similar, e.g. by consequently using a 
"my_i18n" function, adding some pre-processor which extracts the 
strings, and some translation facility. I think implementing a simple 
version should be relatively straight forward.

Note: One problem with i18n is the order. In C one usually uses printf - 
and translates strings such as "Please press button %c after reading 
instruction %d\n"; gettext allows now to revert the order: "After 
checking instruction %$2d, press button %$1c\n". (I hope I got the 
syntax correct.) The way Fortran's transfer statements work, the 
reversal is kind of difficult.

> * gfortran>= 4.4 has some plumbing for wide characters in place,
> though not for UTF-8. Then again, UCS-4 is surely enough for my
> purposes.

Well, you need to distinguish: Fortran internally uses UCS-4, i.e. 4 
byte wide characters. It makes sense to have internally the same width 
for a character - otherwise, you easily end up with a mess. Think of 
assigning character strings, think of LEN, TRIM, TRIM_LEN etc. However, 
for formatted I/O gfortran uses UTF-8. (While UCS-4 is used for 
unformatted I/O.)

In terms of i18n support of gfortran itself: It is considered (low 
priority) to i18n the run-time error messages of libgfortran. 
Additionally, as Jerry mentioned, it is planned to support source code 
written in UTF-8, i.e. one can directly write UTF-8 character in strings 
- whichout using either char(..., kind=...) or backslashes for input.

Tobias