On 14/9/14 16:18, Peter Schorsch wrote:
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
Why that?
Honestly, I am surprised that pharo does not work fully with utf8
(see MathOntology discussion) and has no well documentated and working
localization.
Evolution is more difficult than writing a new language in 2014!
If I understood something wrong please correct me - I still want to
learn pharo and seaside :)
