> Localization is very basic functionality that should be provided by
> the platform itself. We are in the situation that we are in only
> because people see Pharo as something “to build on top”.
>
> This way everyone does their own I18N stuff, while the right thing
> would be to have *one* that is good and part or Pharo itself.
>
> Just think about it: Pharo itself should have translated menus. So we
> need *something* in the system anyway. Why then not make it good and
> make it the one that everyone is using?
As a beginner with pharo I TOTALLY agree with that statement. E.g. so
far I understood there are 3 different localization existing:
* System internal localization
- never seen before, never read about before
* Gettext
- does not work
* QCMagritte
- shall work, did not managed it by myself. Only uses csv
table if I understood correctly.
Here is my suggestion (keep in mind that I did not fully understood
QCMagritte atm). My wish is a localization that:
* supports the gettext format for in and output
* has fallback options if a phrase is not translated
* pharo internal interface maybe a Dictionary
* support of different number formats (e.g. date etc.)
* does NOT depend on the env locales - only the IDE of pharo
Honestly, I am surprised that pharo does not work fully with utf8
(see MathOntology discussion) and has no well documentated and working
localization.
If I understood something wrong please correct me - I still want to
learn pharo and seaside :)
