EiffelStudio: an EiffelSoftware project - User contributions [en]

Internationalization/translation

2006-06-22T11:44:25Z

Kiwi:

[[Category:Internationalization]]

The translation of EiffelStudio is going on [http://slhk.ath.cx/projects/estudio/ here].

EiffelStudio contains many sectorial terms, wich may have a corresponding expression in other languages but their meaning may not be clear enough to the end user.

This page is intended for discussion on terms difficult to translate.

----

Ancestor
* it: Antenato
* fr: Ancêtre

Callers
* it: chiamanti
*fr: ''Appeleur'' is a possiblity but it sounds ugly and is possibly not common usage

Finalize
* it: finalizza -> finalized == finalizzato

Parent
* it: genitore

Put Handle Left

Step Out

Suppliers
* it: fornitori

Toggle visibility
* it: Mostra/nascondi ''[used]''

Watch
* it: osserva

Wizard
* it: Procedura guidata ''[used]'', wizard ''[used in menu]''

Heir
* it: Erede => Heirs: eredi

----
Following words are left unchanged
* it: file, inheritance, overflow, stack, feature, routine, cluster, deferred, client, supplier, signature

Talk:Internationalization/feasibility

2006-05-06T21:28:38Z

Kiwi:

==Unicode support==
A report on the current support for Unicode in Gobo has been requested (see [http://origo.ethz.ch/pipermail/es-vision/2006-April/000002.html here]) but may not come in time for us to profit.
It seems like there are two efforts to support Unicode, one for Gobo and one for EiffelVision, that are still sort of independent from oneanother. --[[User:Carlo|Carlo]] 22:36, 29 April 2006 (CEST)
:I'm meant to investigate that. I shall eventually (before 5th May) but one thing is clear: it's a bit of a mess.
:It is not clear why there are two classes that model unicode strings. We have STRING32. Fine. (Well, not fine actually, because it takes WIDE_CHARACTERs as elements and it is not at first glance obvious how you assign a meaning to a WIDE_CHARACTER (No,wait, I've found out. You can convert an integer into a WIDE_CHARACTER. Unless I am missing something, this is slighly impractical). It even has this strange little thing with WIDE_CHARACTER inheriting from a class called something like my WIDE_CHARACTER_REF ''which has a WIDE_CHARACTER as an attribute''. This, at 2.am, does not seem right at all. ) Then we have some string classes for modelling UTF encodings. Ok. But they descend from the normal STRING. These will have to be investigated at a later date because Eiffel Studio - an offical build, mind you, not self compiled - is segfaulting.

==Momentary Unicode-output support==

...The sequence %/code/, where code is an unsigned integer in any of the available forms--decimal, binary,
octal, hexadecimal--corresponding to a valid character code in the chosen character set.
It allows you to denote any Unicode or Extended ASCII character by its integer code; for
exemple %/59/ represents a semicolon (the character of code 59). Since listings for character
codes--for example in Unicode documentation--often give them in base 16, you may use the 0xNNN convention
for hexadecimal integers: the semicolon example can also be expressed as %/0x3B/, where 3B is the hexadecimal
code for 59.

Since the three cases define all the possibilities, a percent sign is illegal in a context expecting a
Character unless immediately followed by /code/ where code is a legal character code. For example %? is
illegal (no such special character); so is %/0xFFFFFF/ (not in the Unicode range)...
ECMA-STANDARD 367

Momentary is just supported the syntax "%/code/" (STRING_32) or '%/code/' (WIDE_CHARACTER) where code is a decimal in the range 0-255.

More details about syntax definition of Manifest Character at 8.32.22 in the [http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-367.pdf ECMA Standard]

Talk:Internationalization/feasibility

2006-05-06T21:27:52Z

Kiwi:

Talk:Internationalization/feasibility

2006-05-06T21:25:20Z

Kiwi: /* Momentary Unicode-output support */

==Unicode support==
A report on the current support for Unicode in Gobo has been requested (see [http://origo.ethz.ch/pipermail/es-vision/2006-April/000002.html here]) but may not come in time for us to profit.
It seems like there are two efforts to support Unicode, one for Gobo and one for EiffelVision, that are still sort of independent from oneanother. --[[User:Carlo|Carlo]] 22:36, 29 April 2006 (CEST)
:I'm meant to investigate that. I shall eventually (before 5th May) but one thing is clear: it's a bit of a mess.
:It is not clear why there are two classes that model unicode strings. We have STRING32. Fine. (Well, not fine actually, because it takes WIDE_CHARACTERs as elements and it is not at first glance obvious how you assign a meaning to a WIDE_CHARACTER (No,wait, I've found out. You can convert an integer into a WIDE_CHARACTER. Unless I am missing something, this is slighly impractical). It even has this strange little thing with WIDE_CHARACTER inheriting from a class called something like my WIDE_CHARACTER_REF ''which has a WIDE_CHARACTER as an attribute''. This, at 2.am, does not seem right at all. ) Then we have some string classes for modelling UTF encodings. Ok. But they descend from the normal STRING. These will have to be investigated at a later date because Eiffel Studio - an offical build, mind you, not self compiled - is segfaulting.

==Momentary Unicode-output support==

...The sequence %/code/, where code is an unsigned integer in any of the available forms--decimal, binary,
octal, hexadecimal--corresponding to a valid character code in the chosen character set.
It allows you to denote any Unicode or Extended ASCII character by its integer code; for
exemple %/59/ represents a semicolon (the character of code 59). Since listings for character
codes--for example in Unicode documentation--often give them in base 16, you may use the 0xNNN convention
for hexadecimal integers: the semicolon example can also be expressed as %/0x3B/, where 3B is the hexadecimal
code for 59.

Since the three cases define all the possibilities, a percent sign is illegal in a context expecting a
Character unless immediately followed by /code/ where code is a legal character code. For example %? is
illegal (no such special character); so is %/0xFFFFFF/ (not in the Unicode range)...
ECMA-STANDARD 367

Momentary is just supported the syntax "%/code/"(STRING_32) or '%/code/'(WIDE_CHARACTER) where code is a decimal in the range 0-255.

More details about syntax definition of Manifest Character at 8.32.22 in the [http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-367.pdf ECMA Standart]

Talk:Internationalization/feasibility

2006-05-06T21:22:02Z

Kiwi:

==Unicode support==
A report on the current support for Unicode in Gobo has been requested (see [http://origo.ethz.ch/pipermail/es-vision/2006-April/000002.html here]) but may not come in time for us to profit.
It seems like there are two efforts to support Unicode, one for Gobo and one for EiffelVision, that are still sort of independent from oneanother. --[[User:Carlo|Carlo]] 22:36, 29 April 2006 (CEST)
:I'm meant to investigate that. I shall eventually (before 5th May) but one thing is clear: it's a bit of a mess.
:It is not clear why there are two classes that model unicode strings. We have STRING32. Fine. (Well, not fine actually, because it takes WIDE_CHARACTERs as elements and it is not at first glance obvious how you assign a meaning to a WIDE_CHARACTER (No,wait, I've found out. You can convert an integer into a WIDE_CHARACTER. Unless I am missing something, this is slighly impractical). It even has this strange little thing with WIDE_CHARACTER inheriting from a class called something like my WIDE_CHARACTER_REF ''which has a WIDE_CHARACTER as an attribute''. This, at 2.am, does not seem right at all. ) Then we have some string classes for modelling UTF encodings. Ok. But they descend from the normal STRING. These will have to be investigated at a later date because Eiffel Studio - an offical build, mind you, not self compiled - is segfaulting.

==Momentary Unicode-output support==

...The sequence %/code/, where code is an unsigned integer in any of the available forms--decimal, binary,
octal, hexadecimal--corresponding to a valid character code in the chosen character set.
It allows you to denote any Unicode or Extended ASCII character by its integer code; for
exemple %/59/ represents a semicolon (the character of code 59). Since listings for character
codes--for example in Unicode documentation--often give them in base 16, you may use the 0xNNN convention
for hexadecimal integers: the semicolon example can also be expressed as %/0x3B/, where 3B is the hexadecimal
code for 59.

Since the three cases define all the possibilities, a percent sign is illegal in a context expecting a
Character unless immediately followed by /code/ where code is a legal character code. For example %? is
illegal (no such special character); so is %/0xFFFFFF/ (not in the Unicode range)...
ECMA-STANDARD 367
More details about syntax definition of Manifest Character at 8.32.22 in the [http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-367.pdf ECMA Standart]

Talk:Internationalization/feasibility

2006-05-06T21:08:04Z

Kiwi: /* Momentary Unicode-output support */

Talk:Internationalization/feasibility

2006-05-06T21:00:23Z

Kiwi:

Internationalization

2006-05-06T20:55:25Z

Kiwi: /* Possible future developments */

[[Category:Projects]]
[[Image:ebabylon.png|right|frame| Our Eiffel Tower of Babylon]]

=Overview=

''"Many [people] would simply love seeing their computer screen showing a lot less of English, and far more of their own language."'' -- gettext doc

Our aim is not only to provide a framework to ease the translation of Eiffel-written applications, allowing the user to chose his/her preferred language at runtime, but also to let the developer access information and formats based on users' locale.

==What is internationalisation?==

The first thing that comes to mind is translation. But internationalisation isn't restricted to enabling translation: it includes making it possible to localise notations (time, date, numbers), measures, paper size, and much more.

==What should we achieve?==
*Applications should be able to load localized strings at runtime and be provided with localized format strings (e.g date format).
*Developers can use tools that automagically extract strings from source code and can try to get them translated in a file to distribute along with the application.
*Users will still be unhappy and get depressed ''but in their own language'', which we can all agree is a significant step forward.

==Who should do the achieving?==
It is clear that our [[User:Carlo|Glorious Leader]] should be credited with any achieving. However he will have to delegate things somewhat, as he is is not [http://en.wikipedia.org/wiki/Aleksei_Grigorievich_Stakhanov Stakhanov].
We can probably divide the project into the following parts, modulo preliminary research:

''This should be probably be completed after we have got past M1''

=Milestones=

==M2: May 5 ==
* [[Internationalization/feasibility|feasibility]]: look at string classes (unicode and not) and how strings are used in EiffelStudio (creation, composition) ''(Ivano, Carlo, Leo, Hong)''
* [[Internationalization/file_format|file format]]: compare existing file formats for dictionaries ''(Etienne, Andreas)''
* [[Internationalization/tool_evaluation|tool evaluation]]: list and compare existing translation tools ''(Christian, Martino)''

==M3: May ??? ==
After today meeting... please review this M3 and express your preferences!
* design:
** file formats: files holding translated strings, PO files ''(Leo?)''
** [[Internationalization/code_parser|code parser]]: extract strings to be translated from source code aka parsing MO files ''([[User:etienner|Etienne]], Martino?)''
** globality: how to implement, the object should be shared between all modules ''()''
* compile a list of basic features to provide (e.g. date/time format, system locale) ''()''
* collaborate with the [[Vision2_and_Unicode]] team

= Possible future developments =

* collaborate with the [[ESWizard]] team. Create wizards for programms with translation facilities.

=Relevant Links=
[http://www.debian.org/doc/manuals/intro-i18n/ Introduction to i18n]

==What other people have done==
[http://doc.trolltech.com/4.1/i18n.html internationalisation with QT]

[http://oss.erdfunkstelle.de/kde-i18n/tiki-index.php?page=miniHowtoGui howto for internationalisation of KDE programs ]

[http://l10n.kde.org/docs/translation-howto/ another KDE howto (doesn't Gnome do any internationalisation?)]

=Team=

Everyone interested in this project is welcome to [http://origo.ethz.ch/cgi-bin/mailman/listinfo/es-i18n join our mailinglist] es-i18n@origo.ethz.ch

* Project Leader: [[User:Carlo|Carlo Vanini]]
* [[User:leo| Leo Fellmann]]
* [[User:kiwi| Ivano Somaini]]
* [[User:murbi|Andreas Murbach]]
* [[User:etienner|Etienne Reichenbach]]
* [[User:hong |Hong Zhang]]
* [[User:cconti | Christian Conti]]
* [[User:Trosim |Martino Trosi]]
* [[User:Schoelle| Bernd Schoeller]]

Internationalization

2006-05-06T20:54:38Z

Kiwi: /* Possible future developments */

[[Category:Projects]]
[[Image:ebabylon.png|right|frame| Our Eiffel Tower of Babylon]]

=Overview=

''"Many [people] would simply love seeing their computer screen showing a lot less of English, and far more of their own language."'' -- gettext doc

Our aim is not only to provide a framework to ease the translation of Eiffel-written applications, allowing the user to chose his/her preferred language at runtime, but also to let the developer access information and formats based on users' locale.

==What is internationalisation?==

The first thing that comes to mind is translation. But internationalisation isn't restricted to enabling translation: it includes making it possible to localise notations (time, date, numbers), measures, paper size, and much more.

==What should we achieve?==
*Applications should be able to load localized strings at runtime and be provided with localized format strings (e.g date format).
*Developers can use tools that automagically extract strings from source code and can try to get them translated in a file to distribute along with the application.
*Users will still be unhappy and get depressed ''but in their own language'', which we can all agree is a significant step forward.

==Who should do the achieving?==
It is clear that our [[User:Carlo|Glorious Leader]] should be credited with any achieving. However he will have to delegate things somewhat, as he is is not [http://en.wikipedia.org/wiki/Aleksei_Grigorievich_Stakhanov Stakhanov].
We can probably divide the project into the following parts, modulo preliminary research:

''This should be probably be completed after we have got past M1''

=Milestones=

==M2: May 5 ==
* [[Internationalization/feasibility|feasibility]]: look at string classes (unicode and not) and how strings are used in EiffelStudio (creation, composition) ''(Ivano, Carlo, Leo, Hong)''
* [[Internationalization/file_format|file format]]: compare existing file formats for dictionaries ''(Etienne, Andreas)''
* [[Internationalization/tool_evaluation|tool evaluation]]: list and compare existing translation tools ''(Christian, Martino)''

==M3: May ??? ==
After today meeting... please review this M3 and express your preferences!
* design:
** file formats: files holding translated strings, PO files ''(Leo?)''
** [[Internationalization/code_parser|code parser]]: extract strings to be translated from source code aka parsing MO files ''([[User:etienner|Etienne]], Martino?)''
** globality: how to implement, the object should be shared between all modules ''()''
* compile a list of basic features to provide (e.g. date/time format, system locale) ''()''
* collaborate with the [[Vision2_and_Unicode]] team

= Possible future developments =

* collaborate with the [[ESWizard]] group. Create wizards for programms with translation facilities.

=Relevant Links=
[http://www.debian.org/doc/manuals/intro-i18n/ Introduction to i18n]

==What other people have done==
[http://doc.trolltech.com/4.1/i18n.html internationalisation with QT]

[http://oss.erdfunkstelle.de/kde-i18n/tiki-index.php?page=miniHowtoGui howto for internationalisation of KDE programs ]

[http://l10n.kde.org/docs/translation-howto/ another KDE howto (doesn't Gnome do any internationalisation?)]

=Team=

Everyone interested in this project is welcome to [http://origo.ethz.ch/cgi-bin/mailman/listinfo/es-i18n join our mailinglist] es-i18n@origo.ethz.ch

* Project Leader: [[User:Carlo|Carlo Vanini]]
* [[User:leo| Leo Fellmann]]
* [[User:kiwi| Ivano Somaini]]
* [[User:murbi|Andreas Murbach]]
* [[User:etienner|Etienne Reichenbach]]
* [[User:hong |Hong Zhang]]
* [[User:cconti | Christian Conti]]
* [[User:Trosim |Martino Trosi]]
* [[User:Schoelle| Bernd Schoeller]]

Internationalization/feasibility

2006-05-01T11:45:29Z

Kiwi:

==Summary==
Our task is to find out the possible main difficulties that will be encoutered during both design and implementation of the [[internationalization|i18n]] framework.

Main focuses are:
* state of the Unicode implementation
* strings usage in Vision2
* runtime generated/composed strings with variables

==String types and their possible difficulties==

===Constant String===
Workbench_name: STRING is "EiffelStudio"

====Difficulties====
====Possible Solution====

===String with label specific syntax===
m_to_lower: STRING is "Set to &Lowercase%TCtrl+Shift+U"

====Difficulties====
* Bad readability for the traducer
* Shortcuts conflict
====Possible Solution====

===Composed String===
m_About:STRING is
once
Result:"&About"+ Workbench_name + "..."
end

====Difficulties====
====Possible Solution====

===Runtime composed String containging queries===
w_Project_directory_not_exist (file_name, dir_name: STRING):STRING is
do
create Result.make(256)
Result.append ("%NCannot open project '")
Result.append (file_name)
Result.append ("'.%N%NMake sure you have a complete EIFGEN directory in '")
Result.append (dir_name)
Result.append ("'.")
end

====Difficulties====
====Possible Solution====
==Important Classes==

====Defining and formatting Strings====

* INTERFACE_NAMES: Include all the strings of the ES interface (buttons, labels, shortcuts...)
* TEXT_FORMATTER: Text formatter for all text output formatting
* ERROR: Error object sent by the compiler to the workbench. Ancestor class of all error classes (WARNING, SYNTAX_ERROR, INTERRUPT_ERROR, LACE_ERROR,EIFFEL_ERROR...)

====Implementations====

* STRING_GENERAL: "Common ancestors to all STRING classes." [base]
** STRING: [base]
*** UC_STRING: Unicode strings [gobo]
**** UC_UTF8_STRING: Unicode strings with UTF-8 encoding
** STRING_32: [base]
* UC_CHARACTER: Unicode characters [gobo]

* KS_STRING: Portable interface for class STRING [Gobo]
* cluster: "gobo.kernel.unicode"

* WIDE_CHARACTER: Unicode characters, with comparison operations [base]

Internationalization/feasibility

2006-05-01T11:43:41Z

Kiwi:

==Summary==
Our task is to find out the possible main difficulties that will be encoutered during both design and implementation of the [[internationalization|i18n]] framework.

Main focuses are:
* state of the Unicode implementation
* strings usage in Vision2
* runtime generated/composed strings with variables

==String types and their possible difficulties==

===Constant String===
Workbench_name: STRING is "EiffelStudio"

====Difficulties====
====Possible Solution====

===String with label specific syntax===
m_to_lower: STRING is "Set to &Lowercase%TCtrl+Shift+U"

====Difficulties====
* Bad readability for the traducer
* Shortcuts conflict
====Possible Solution====

===Composed String===
m_About:STRING is
once
Result:"&About"+ Workbench_name + "..."
end

====Difficulties====
====Possible Solution====

===Runtime composed String containging queries===
w_Project_directory_not_exist (file_name, dir_name: STRING):STRING is
do
create Result.make(256)
Result.append ("%NCannot open project '")
Result.append (file_name)
Result.append ("'.%N%NMake sure you have a complete EIFGEN directory in '")
Result.append (dir_name)
Result.append ("'.")
end
==Important Classes==

====Defining and formatting Strings====

* INTERFACE_NAMES: Include all the strings of the ES interface (buttons, labels, shortcuts...)
* TEXT_FORMATTER: Text formatter for all text output formatting
* ERROR: Error object sent by the compiler to the workbench. Ancestor class of all error classes (WARNING, SYNTAX_ERROR, INTERRUPT_ERROR, LACE_ERROR,EIFFEL_ERROR...)

====Implementations====

* STRING_GENERAL: "Common ancestors to all STRING classes." [base]
** STRING: [base]
*** UC_STRING: Unicode strings [gobo]
**** UC_UTF8_STRING: Unicode strings with UTF-8 encoding
** STRING_32: [base]
* UC_CHARACTER: Unicode characters [gobo]

* KS_STRING: Portable interface for class STRING [Gobo]
* cluster: "gobo.kernel.unicode"

* WIDE_CHARACTER: Unicode characters, with comparison operations [base]

Internationalization/feasibility

2006-05-01T11:25:10Z

Kiwi:

==Summary==
Our task is to find out the possible main difficulties that will be encoutered during both design and implementation of the [[internationalization|i18n]] framework.

Main focuses are:
* state of the Unicode implementation
* strings usage in Vision2
* runtime generated/composed strings with variables

==String types and their possible difficulties==

===Constant String===
Workbench_name: STRING is "EiffelStudio"

====Difficulties====
====Possible Solution====

===String with label specific syntax===
m_to_lower: STRING is "Set to &Lowercase%TCtrl+Shift+U"

====Difficulties====
* Bad readability for the traducer
* Shortcuts conflict
====Possible Solution====

===Composed String===
m_About:STRING is
once
Result:"&About" + Workbench_name + "..."
end

====Difficulties====
====Possible Solution====

==Important Classes==

* INTERFACE_NAMES: Include all the strings of the ES interface (buttons, labels, shortcuts...)
* TEXT_FORMATTER: Text formatter for all text output formatting

* STRING_GENERAL: "Common ancestors to all STRING classes." [base]
** STRING: [base]
*** UC_STRING: Unicode strings [gobo]
**** UC_UTF8_STRING: Unicode strings with UTF-8 encoding
** STRING_32: [base]
* UC_CHARACTER: Unicode characters [gobo]

* KS_STRING: Portable interface for class STRING [Gobo]
* cluster: "gobo.kernel.unicode"

* ERROR: Error object sent by the compiler to the workbench. Ancestor class of all error classes (WARNING, SYNTAX_ERROR, INTERRUPT_ERROR, LACE_ERROR,EIFFEL_ERROR...)

* WIDE_CHARACTER: Unicode characters, with comparison operations [base]

Internationalization/feasibility

2006-05-01T11:23:42Z

Kiwi:

Internationalization/feasibility

2006-05-01T11:13:20Z

Kiwi:

Internationalization/feasibility

2006-05-01T11:11:00Z

Kiwi: /* Constant String */

Internationalization/feasibility

2006-05-01T10:11:24Z

Kiwi: /* Constant String */

Internationalization/feasibility

2006-05-01T10:09:27Z

Kiwi: /* String types and their possible extraction difficulties */

Internationalization/feasibility

2006-05-01T09:18:06Z

Kiwi:

Internationalization/feasibility

2006-04-30T22:22:20Z

Kiwi:

Internationalization/feasibility

2006-04-30T16:21:08Z

Kiwi:

==Summary==
Our task is to find out the possible main difficulties that will be encoutered during both design and implementation of the [[i18n]] framework.

Main focuses are:
* state of the Unicode implementation
* strings usage in Vision2
* runtime generated/composed strings with variables

==String types and their possible extraction difficulties==

Internationalization/feasibility

2006-04-30T16:04:30Z

Kiwi:

Internationalization

2006-04-26T21:44:22Z

Kiwi:

[[Category:Projects]]
[[Image:ebabylon.png|right|frame| Our Eiffel Tower of Babylon]]

=Overview=

''"Many [people] would simply love seeing their computer screen showing a lot less of English, and far more of their own language."'' -- gettext doc

Our aim is not only to provide a framework to ease the translation of Eiffel-written applications, allowing the user to chose his/her preferred language at runtime, but also to let the developer access information and formats based on users' locale.

==What is internationalisation?==

The first thing that comes to mind is translation. But internationalisation isn't restricted to enabling translation: it includes making it possible to localise notations (time, date, numbers), measures, paper size, and much more.

==What should we achieve?==
*Applications should be able to load localized strings at runtime and be provided with localized format strings (e.g date format).
*Developers can use tools that automagically extract strings from source code and can try to get them translated in a file to distribute along with the application.
*Users will still be unhappy and get depressed ''but in their own language'', which we can all agree is a significant step forward.

==Who should do the achieving?==
It is clear that our [[User:Carlo|Glorious Leader]] should be credited with any achieving. However he will have to delegate things somewhat, as he is is not [http://en.wikipedia.org/wiki/Aleksei_Grigorievich_Stakhanov Stakhanov].
We can probably divide the project into the following parts, modulo preliminary research:

''This should be probably be completed after we have got past M1''

=Milestones=

==M2: May 5 ==
* [[Internationalization/feasibility|feasibility]]: look at string classes (unicode and not) and how strings are used in EiffelStudio (creation, composition) ''(Ivano, Carlo)''
* [[Internationalization/file_format|file format]]: compare existing file formats for dictionaries ''(Etienne, Andreas)''
* [[Internationalization/tool_evaluation|tool evaluation]]: list and compare existing translation tools ''(Christian, Martino)''

==M3: May ??? ==
* design:
** file formats (files holding translated strings)
** code parser (extract strings to be translated from source code)
** globality (how to implement, the object should be shared between all modules)
* compile a list of basic features to provide (e.g. date/time format, system locale)
* collaborate with the [[Vision2_and_Unicode]] team

= Possible future developments =

=Relevant Links=
==What other people have done==
[http://doc.trolltech.com/4.1/i18n.html internationalisation with QT]

[http://oss.erdfunkstelle.de/kde-i18n/tiki-index.php?page=miniHowtoGui howto for internationalisation of KDE programs ]

[http://l10n.kde.org/docs/translation-howto/ another KDE howto (doesn't Gnome do any internationalisation?)]

=Team=

Everyone interested in this project is welcome to [http://origo.ethz.ch/cgi-bin/mailman/listinfo/es-i18n join our mailinglist] es-i18n@origo.ethz.ch

* Project Leader: [[User:Carlo|Carlo Vanini]]
* [[User:leo| Leo Fellmann]]
* [[User:kiwi| Ivano Somaini]]
* [[User:murbi|Andreas Murbach]]
* [[User:etienner|Etienne Reichenbach]]
* [[User:hong |Hong Zhang]]
* [[User:cconti | Christian Conti]]
* [[User:Trosim |Martino Trosi]]
* [[User:Schoelle| Bernd Schoeller]]

Internationalization/feasibility

2006-04-26T21:43:16Z

Kiwi:

User:Kiwi

2006-04-26T15:39:41Z

Kiwi:

Yeah, I blossom like [[User:leo| Leo Fellmann]] :-)

User:Kiwi

2006-04-26T15:34:52Z

Kiwi:

Yeah, I blossom!

Internationalization

2006-04-26T15:34:09Z

Kiwi: /* Team */

[[Category:Projects]]
[[Image:ebabylon.png|right|frame| Our Eiffel Tower of Babylon]]

=Overview=

''"Many [people] would simply love seeing their computer screen showing a lot less of English, and far more of their own language."'' -- gettext doc

Our aim is not only to provide a framework to ease the translation of Eiffel-written applications, allowing the user to chose his/her preferred language at runtime, but also to let the developer access information and formats based on users' locale.

==What is internationalisation?==

The first thing that comes to mind is translation. But internationalisation isn't restricted to enabling translation: it includes making it possible to localise notations (time, date, numbers), measures, paper size, and much more.

==What should we achieve?==
*Applications should be able to load localized strings at runtime and be provided with localized format strings (e.g date format).
*Developers can use tools that automagically extract strings from source code and can try to get them translated in a file to distribute along with the application.
*Users will still be unhappy and get depressed ''but in their own language'', which we can all agree is a significant step forward.

==Who should do the achieving?==
It is clear that our [[User:Carlo|Glorious Leader]] should be credited with any achieving. However he will have to delegate things somewhat, as he is is not [http://en.wikipedia.org/wiki/Aleksei_Grigorievich_Stakhanov Stakhanov].
We can probably divide the project into the following parts, modulo preliminary research:

''This should be probably be completed after we have got past M1''

=Milestones=

==M2: May 5 ==
* feasibility: look at string classes (unicode and not) and how strings are used in EiffelStudio (creation, composition) ''(Ivano, Carlo)''
* [[Internationalization/file_format|file format]]: compare existing file formats for dictionaries ''(Etienne, Andreas H.)''
* [[Internationalization/tool_evaluation|tool evaluation]]: list and compare existing translation tools ''(Christian, Martino)''

==M3: May ??? ==
* design:
** file formats (files holding translated strings)
** code parser (extract strings to be translated from source code)
** globality (how to implement, the object should be shared between all modules)
* compile a list of basic features to provide (e.g. date/time format, system locale)
* collaborate with the [[Vision2_and_Unicode]] team

= Possible future developments =

=Relevant Links=
==What other people have done==
[http://doc.trolltech.com/4.1/i18n.html internationalisation with QT]

[http://oss.erdfunkstelle.de/kde-i18n/tiki-index.php?page=miniHowtoGui howto for internationalisation of KDE programs ]

[http://l10n.kde.org/docs/translation-howto/ another KDE howto (doesn't Gnome do any internationalisation?)]

=Team=

Everyone interested in this project is welcome to [http://origo.ethz.ch/cgi-bin/mailman/listinfo/es-i18n join our mailinglist] es-i18n@origo.ethz.ch

* Project Leader: [[User:Carlo|Carlo Vanini]]
* [[User:leo| Leo Fellmann]]
* [[User:kiwi| Ivano Somaini]]
* [[User:murbi|Andreas Murbach]]
* [[User:etienner|Etienne Reichenbach]]
* [[User:hong |Hong Zhang]]
* [[User:cconti | Christian Conti]]
* [[User:Trosim |Martino Trosi]]
* [[User:Schoelle| Bernd Schoeller]]