Talk:EiffelStudio Internationalization

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

/usr/share/locale

e.g.

/usr/share/locale/en/LC_MESSAGES/eiffelstudio.mo
/usr/share/locale/de/LC_MESSAGES/eiffelstudio.mo
/usr/share/locale/de_CH/LC_MESSAGES/eiffelstudio.mo

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

I agree. -- Ted 08:04, 2 July 2008 (PDT)

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)

Yes, one can not tell the encoding accurately. I thought this could be possible done by combination of means. I knew firefox and IE has encoding detection library, but they seem only give the most possible results, not accurate ones. This part maybe implemented as just "encoding detection" in the end. --Ted 08:13, 2 July 2008 (PDT)

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:

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

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

This is one way we are thinking of. But ideally this needs parsing. Maybe specifying encoding as compiler argument is good enough, or make it into .ecf files. --Ted 08:18, 2 July 2008 (PDT)

All XML files support all of Unicode

The line that says ECF files, etc., will need a Unicode encoding is not true. All XML files, no matter what their encoding, support the entire Unicode character set. --Colin-adams 22:41, 1 July 2008 (PDT)