I have been disappointed by webL10n from Day One. I have a bunch of supporting scripts but it is not very expressive and as you note, having a huge ini file is not optimal, I was planning to explore options this summer as part of Music Blocks 4.0. But had not started researching yet.
-walter On Sun, May 16, 2021 at 4:08 PM Lionel Laské <lionel.la...@gmail.com> wrote: > > > Hi all, > > From the beginning, Sugarizer relies on the webL10n library [1] to handle > localization from Javascript. > This library uses a .INI file where localizations are stored and loaded > during page initialization. > Sounds like MusicBlocks use the same library too. > > I'm thinking to change localization library in a future version of Sugarizer > because: > > webL10n has been deprecated since 2015 > a pivot file format (PO Gettext) is used to be able to localize strings in > the Sugarizer translate platform [2]. It made the update process complex (INI > to PO then PO to INI). > all language localizations are located in a huge file (260kb) that is not > good for performance reasons. > > I've done a short study here [3] to test another localization library i18next > [4]. > i18next is independent from any Javascript framework, largely supported and > easy to use. > > So I'm thinking to switch to i18next. > Is there any plan to change the localization library in MusicBlocks? > Do you experience another localization library? > > Regards. > > Lionel > > [1] https://github.com/fabi1cazenave/webL10n > [2] https://translate.sugarizer.org > [3] https://github.com/llaske/l10nstudy > [4] https://github.com/i18next/i18next > _______________________________________________ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel