[Sugar-devel] Handling of localization in Sugarizer/MusicBlocks

[Walter Bender]

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.laske at 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 at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org