Talk:EiffelStudio Internationalization

Revision as of 23:17, 31 July 2007 by Colin-adams (Talk | contribs) (Notes term)

--Patrickr 17:31, 9 November 2006 (CET)

The location for the mo files should be setup in the environment library, on Unix those files go under




--Juliant 19:53, 10 November 2006 (CET)

Is it really necessary that the language can be changed while running EiffelStudio? I would say this is set once (even during installation). It wouldn't be a problem to just restart EiffelStudio.

--Ted 03:20, 13 November 2006 (CET)

What are the advantages of putting mo files under /usr/share/locale? mo files are not shared between applications and normally users do not need to change mo files.
All mo files are put in ES installation directory, we only need to store the locale id as a preference.
More over, mo files are implemented to be accepted by the library only with names of locale id.
We need to decide whether the language can be switched at runtime. Of course, not doing this as most applications definitely reduces a lot of time.

--Patrickr 17:13, 13 November 2006 (CET)

On Unix there are rules where which part of an application belongs to. Standardising this locations makes various things easier. I also think changing the language during runtime is not necessary.

Dont use UTF-16

UTF-16 is an abomination - it should never be used. --Colin-adams 09:03, 1 August 2007 (CEST)

Auto-encoding detection

Do you have a scheme in mind?

This is, in general, impossible, but special circumstances can make it tractable. The starting possibilities for an Eiffel source text are quite limited, so at first glance it looks possible.

However, I note that if an Eiffel source text uses ASCII characters for everything except the contents of STRING_8 literals, and no STRING_32 or CHARACTER_32 literals are present, then it will be impossible to distinguish between ISO-8859-1 (or most other subsets of ISO-8859) and UTF-8, unless the UTF-8 file starts with a BOM. But the latter practise is reprehensible, and many editors do not support it.

--Colin-adams 09:09, 1 August 2007 (CEST)

Notes term

The problem becomes much simpler if you add the following restriction:

Source codings other than ISO-646 (US-ASCII) and ISO-8859-1 (Latin-1) are only allowed if the class contains an encoding term in the notes (indexing, in pre-ECMA) clause whose value names the encoding.

So a UTF-8 source file would start something like:

 description: "My latest class writen in Unicode"
 encoding: "UTF-8"

--Colin-adams 09:17, 1 August 2007 (CEST)