FES + i18n: Load translations from a CDN

[akshay-99]

Resolves #4694

Changes:

• Publish translation files to a CDN with every release. I have set it up so that the contents under the path translations/** get published to NPM. From there, jsDelivr can cache it to their CDN.
  I published a namespaced version to test this out and it seems to work
  https://cdn.jsdelivr.net/npm/@akshay-99/[email protected]/translations/es/translation.json
  https://cdn.jsdelivr.net/npm/@akshay-99/[email protected]/translations/en/translation.json

These changes would take effect from the next release. Before then, the configured path ( https://cdn.jsdelivr.net/npm/p5/translations/ ) would give us a 404. This wouldn't be a problem for contributors because of the next point below.

• Use local translation files in dev mode. Whenever someone is adding/updating something, they should be able to test it out. Fetching from the CDN will not be helpful as these changes wouldn't have been published yet. I configured grunt and browserify to pack all the translation files in the library when running browserify:dev ( i.e with npm run dev but not with npm run build )

Also, since we have updated our default branch name to main, we may have to change something with np to let it know this. Otherwise it complains that we aren't on the correct branch and would stop the release. For testing out this PR, I just manually passed in --any-branch. But there must be some other way to let np know the name of the default branch.

PR Checklist

• npm run lint passes
• Inline documentation is included / updated
• Unit tests are included / updated

[limzykenneth]

It is possible to publish the files to cdnjs as well, probably just need to make a PR to edit this file.

A fix for np might be coming soon: sindresorhus/np#558. In the meantime to release from main, --any-branch should be used for now. I'll put together a PR for this for the time being.

[akshay-99]

It is possible to publish the files to cdnjs as well, probably just need to make a PR to edit this file.

Yes. I will look into it.

[lmccart]

This looks great. Could we add some link in the contributor_docs/ to the files that are necessary to update when adding another language? (And any other relevant links) I think it would go in the internationalization.md file.

[akshay-99]

Hi. Yes. I will add that too.

[stalgiag]

Great! Two small simple questions inline. I am working with the assumption that we will have some time to look at this in more depth later to make sure that it is easy enough for others to maintain and build upon.

[akshay-99]

I am working with the assumption that we will have some time to look at this in more depth later to make sure that it is easy enough for others to maintain and build upon.

One part that might be a bit difficult to maintain is this. There are already several i18next plugins available that do something similar like i18next-http-backend, i18next-fetch-backend. But there were two things which I didn't find a way to implement using these: quickly skip a language if it doesn't exist in the list of supported languages ( don't send a request ), and timeout a request if it takes too much time.

Since we are stalling the initialization waiting for the translations to finish downloading, it may be important that this step doesn't take too much time as well ensure that it doesn't spend time trying to find files for languages which we know aren't supported yet. This may be important when there is a chain of unsupported languages. For example, if someone's browser language is fr-CA ( Canadian French ), i18next will try to find fr-CA and since that isn't supported yet, try looking up fr. Since that too isn't supported, it finally comes to English. But it just spent time on two requests, which is easily prevented by just checking against a list of supported languages.

[akshay-99]

I think adding a language itself should be easy for contributors since ( apart from the actual translation itself ) it only involves adding two extra lines in the code, here and here.

[stalgiag]

Since we are stalling the initialization waiting for the translations to finish downloading, it may be important that this step doesn't take too much time as well ensure that it doesn't spend time trying to find files for languages which we know aren't supported yet. This may be important when there is a chain of unsupported languages. For example, if someone's browser language is fr-CA ( Canadian French ), i18next will try to find fr-CA and since that isn't supported yet, try looking up fr. Since that too isn't supported, it finally comes to English. But it just spent time on two requests, which is easily prevented by just checking against a list of supported languages.

Thanks for explaining this in detail. I think that quickly skipping unsupported languages should be a priority for future work.