Re: multilingual programs
On Wed, 29 Mar 2000, Matthias Mann wrote: Has anybody some experience on what's the best way to write programs that may interact in multiple languages? My first thought was to extract all texts from the source and put them into a big list or array. The program then accesses the list corresponding to the selected language. Any other (better) ideas? Should inputs, e.g. answers to yes-no-questions, be handled the same? Not sure if this is a better idea, but the approach that, from what I can gather, a lot of the GNU programs use is equivalent to replacing every literal string in the text with roughly (lookup language "the string") where lookup::Langauge - String - String and language is (in C) a global variable containing the target language. These strings get looked up at in an external set of translations for various languages at runtime (ie once for each time the string is called) and if a translation is found it's used, otherwise the original string is used. The advantages of this seem to be that (1) translators can provide extra translations without needing a program recompile and (2) it's failsoft so that if there's no translation there's still a string to use, albeit in the language the programmer used and (3) with the _(x) macro it doesn't add `visual noise' to the program logic. The disadvantage of this kind of scheme for haskell is that there's no way to get a user setable global variable without everything going monadic (or you use an unsafe operation) so it'd have to be passed as an explicit argument to every function needing it. Presumably with answers the user types (as opposed to GUI components with labels that they activate) I guess you're into the realm of regular expressions rather than strings. I'd be interested to know if there's a more natural way to do this for haskell. ___cheers,_dave www.cs.bris.ac.uk/~tweed/pi.htm|ALERT: you are communicating with an email: [EMAIL PROTECTED] |unsavoury individual with a copy of gdb work tel: (0117) 954-5253 |who reverse-engineered a file format.
Re: multilingual programs
"D. Tweed" wrote: The disadvantage of this kind of scheme for haskell is that there's no way to get a user setable global variable without everything going monadic (or you use an unsafe operation) so it'd have to be passed as an explicit argument to every function needing it. But I bet 99% of the time you need a string in the local language, you are about to print it out anyway, so the monads are already there. (The other 1% probably consists mostly of calls to the error function . . .)
Re: multilingual programs
"D. Tweed" wrote: [...] The disadvantage of this kind of scheme for haskell is that there's no way to get a user setable global variable without everything going monadic (or you use an unsafe operation) [...] You've already hinted at this, but anyway: After an initialization phase (reading in the global translation table) lookup is a "normal" function, i.e. the translations remain unchanged. IIRC there was a similar discussion about commandline arguments some time ago. This is such a common pattern that there should be a nicer way to handle it apart from the usual unsafePerformIO-plus-noInline-trickery at the top level. Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: multilingual programs
"D. Tweed" [EMAIL PROTECTED] wrote, On Wed, 29 Mar 2000, Matthias Mann wrote: Has anybody some experience on what's the best way to write programs that may interact in multiple languages? Not sure if this is a better idea, but the approach that, from what I can gather, a lot of the GNU programs use is equivalent to replacing every literal string in the text with roughly (lookup language "the string") where lookup::Langauge - String - String and language is (in C) a global variable containing the target language. These strings get looked up at in an external set of translations for various languages at runtime (ie once for each time the string is called) and if a translation is found it's used, otherwise the original string is used. The advantages of this seem to be that (1) translators can provide extra translations without needing a program recompile and (2) it's failsoft so that if there's no translation there's still a string to use, albeit in the language the programmer used and (3) with the _(x) macro it doesn't add `visual noise' to the program logic. The GNU package for i18n is gettext: http://www.gnu.org/software/gettext/gettext.html As Fergus already pointed out, the main issue with this is that it relies on a printf-ish format string to handle the different word ordering in different languages. I'd be very interested in ideas on how to address this problem, because serious application development in Haskell is significantly hampered without i18n support. Anything that could make use of gettext's PO files would of course be especially cool, as it can use the existing infrastructure. Manuel
