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