Difference between revisions of "Talk:Internationalization/feasibility"
m (half-awake mumbling. will delete, expand and correct. later!) |
|||
| Line 2: | Line 2: | ||
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. | 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) | 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. | ||
Revision as of 16:58, 1 May 2006
Unicode support
A report on the current support for Unicode in Gobo has been requested (see 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. --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.
