Difference between revisions of "Internationalization/obstacles"
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | [[Category:Internationalization]] | ||
==Obstacles found during the semester project== | ==Obstacles found during the semester project== | ||
| Line 6: | Line 7: | ||
===EiffelStudio=== | ===EiffelStudio=== | ||
| + | |||
| + | *Formatters require a certain property to be a lowercase string and read this directly from INTERFACE_NAMES, meaning that if the i18n library supplies a translated string that is not lowercase, an exception violation happens. This would superficially be relatively easy to fix, but it is not such a good idea to do this anyway, because with STRING_32 there may not even be a lowercase version of the string (asian scripts come to mind). This behaviour may also happen elsewhere, but I am not sure. | ||
Latest revision as of 10:34, 31 October 2006
Contents
Obstacles found during the semester project
Library
No significant problems. There were some slight hiccups with UTF-16, as the gobo parser expects a BOM and so cannot parse UTF16LE or UTF-16BE. Unluckily for us, windows uses little-endian UTF-16.
EiffelStudio
- Formatters require a certain property to be a lowercase string and read this directly from INTERFACE_NAMES, meaning that if the i18n library supplies a translated string that is not lowercase, an exception violation happens. This would superficially be relatively easy to fix, but it is not such a good idea to do this anyway, because with STRING_32 there may not even be a lowercase version of the string (asian scripts come to mind). This behaviour may also happen elsewhere, but I am not sure.
Problems encountered during the SA project
Problems we encountered during implementation
- Unicode (UTF-8) support was not fully implemented (e.g. for gtk)
- Facilities to write and read STRING_32 to/from files were not present
Difficulties to complete the translation of EiffelStudio:
- Many strings are hard-coded anywhere inside EiffelStudio, making the translation difficult
- All the functions taking strings as arguments expect a STRING, where they should expect a STRING_GENERAL, and they return a STRING which may not be applicable in every case. A STRING_32 can also represent the same content of a STRING_8, thus it should be preferred.
- It seems that to_uppercase and to_lowercase procedures are not defined for STRING_32 and are used in the studio, these should have been implemented by the vision project and may be buggy.
