fontra
fontra copied to clipboard
Basic localization support
Fix #1340
Todos
- [ ] add support to plural forms
- [ ] localize strings that are used directly into html elements
- [x] localize strings that are used directly into html attributes
- [x] read localization data from different .json files instead of hardcoding it inside .js
- [x] a switch-language menu
- [x] changes should be applied without refreshing the page
current workaround: use
location.reload(true)
to reload automatically
Current Issues
- [ ] imperfect Chinese translation
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
View this failed invocation of the CLA check for more information.
For the most up to date status, view the checks section at the bottom of the pull request.
Is there any way to reload the UI without refreshing the whole page?
Is there any way to reload the UI without refreshing the whole page?
Not really. I'd need to look into editor.js, maybe it should get a method to that effect. The closes thing would be is to call editorController.reloadData()
. Hmm, maybe that just works.
Else: what are the downsides of a page reload for what you are doing?
Random idea (to be considered for later, it may not be that relevant for this initial work): should we maintain the translations as a (google-docs or equivalent) spreadsheet, to make it easier to onboard people who can help with providing/fixing/checking translations?
Please run pre-commit install
if you haven't already, that should help keeping the project's formatting as expected.
EditorController.reloadData()
breaks the whole thing 😂
But using
location.reload(true)
(full reload) also has some issues. Some localization data won't load after refreshing multiple times.
But for most times
location.reload(true)
can do the work.
After doing some testing around reloading the web page, I found this issue only appears on Chrome. Safari can load all localization data no matter how you reload. And Chrome sometimes doesn't localize at all, only showing the keys.
This is so weird
Just font out that CMD+R reload on Chrome doesn't ignore cached content, and so does location.reload()
or location.reload(true)
.
Figured out an alternative way to call editorController.reloadData()
, but most of the localization are not reloaded.
Random idea (to be considered for later, it may not be that relevant for this initial work): should we maintain the translations as a (google-docs or equivalent) spreadsheet, to make it easier to onboard people who can help with providing/fixing/checking translations?
Maybe using professional platforms like Crowdin or Transifex is a better idea. They offer free project hosting for open-source repos. But integrating them into current workflow is another problem.
Rebased
But I still cannot figure out a proper way to use editorController.reloadData()
😂
Guess I'll just stick to window.location.reload(true)
About the json prettier plugin: that's fine as long as we have control about which files it will touch. Like, there are .json files in test-common that I'm not sure I want to be touched. There are .json files inside .fontra folder that should not be touched, but I think they are already ignored.
I'm planning to mark this PR as ready, since there're too many files modified. The main editor is almost localized, and for unlocalized dialogs and pop-ups I'll open a second PR after this one's merged.
Please use pre-commit, you may have to run "pre-commit install" to turn it on for this repo.
I notice in the test fail that it reformats some .json files that are unrelated to this PR. I would prefer them to not be changed. Maybe you can activate the json prettier only for the files you are interested in?
I see that if a translation is not found, the key is returned.
I'm worried about new things that will be added, which will be in English first. Imagining we may have more translations in the future, I wonder if we should fall back to english if a translation isn't found. Else we'd be forced to always have all new translations ready at the same time, which seems impractical.
IMO this isn't a big problem right now, since we can still hardcode the English strings in the source code for new strings. I'll add the fallback strategy in the next PR, so that new strings can use translate(key)
directly.
Thanks so much!