jsonschema2md
jsonschema2md copied to clipboard
sbrunner
[draft] Support for localization
This pull request aims to add full support for localization of the output file.
Closes: #465
TO-DO
- [x] Call gettext for every output's string.
- [ ] Allow configuration of the output language.
- [ ] Add development scripts to extract strings and compile
pofiles. - [ ] Add tests.
Currently, I just converted all the strings to a call to gettext.gettext (aliased to _).
The formatting is currently done using printf-style formatting, let me know if you want to change that.
It would also be good to use Babel for some things, like list formatting (instead of ", ".join(...)). It also has functions to extract and compile message catalogs.
I don't have strong preference about the printf-style usually I prefer the template style, but it looks that in the context of gettext, the support is better for printf-style.
+1 for Babel, it's a good addition :-)
Template strings are more verbose because they require calling safe_substitute for every call, and we can't make gettext accept more arguments without also adapting the xgettext program.
We could make gettext return a custom subclass of Template with a one-letter method to make it better though, so _('String $value').s(value=1) could work.
Should we change some json.dumps call to babel.lists.format_list? This would transform Must be one of: ["an", "full", "enum"]. to Must be one of: an, full, or enum.. We could call map with json.dumps to transform the values to a valid representation.
Done that! We shoud test when the object has a type or format, 2 and 3 "attributes" to cover list formatting.
You should also run
pre-commit run --all-files!
pre-commit isn't building on my system (Windows). Will try to run under WSL and commit any changes.
Do you know how to fix those commit errors? Both the spell and the merge commit.
We should probably add a pre-commit hook to automatically extract and maybe update the catalogs. But we should run it after "end-of-line-fixer" because Babel seems to add 2 empty lines at the end.
Also we have to find a way to ship the ".mo" files. We could also run "compile" in the pre-commit, but the ideal solution would be compilation on the user machine, maybe on the first run?
We could also use this, it's unstable though.
We should probably add a pre-commit hook to automatically extract and maybe update the catalogs. But we should run it after "end-of-line-fixer" because Babel seems to add 2 empty lines at the end.
Noce :-), the po file should be ignored in the end-of-line-fixer otherwise the CI will never pass!
Added the build script and correctly setup the necessary include's and ignore's (for sdist and wheel).
But I don't see how we can ignore the pot file in end-of-file-fixer, since I don't see an option for it. Should we ignore the whole file in pre-commit?
We could also .gitignore it entirely, since it doesn't need to be tracked anyway (it's deterministic).
And we could just have a placeholder file in "locales" until we add at least one language. I already translated it to pt_BR for test purposes, but I'm not going to track it here (I'll do another PR for it).
I think it should be good to .gitignore messages.pot, the diff is too large with any change. What do you think?
Also if we add extract and update to pre-commit, we would also have the diff from all po files adding up to this one.
Also, the PR is almost complete! The only thing missing is testing different languages, but it requires at least one translation to do that. My suggestion is copying the already existing tests and just translating them. Did you use something to write the tests's expected output or did you do it by hand?
Hey! I was reading the documentation on the string module, and I came across the Template strings section. It mentions the flufl.i18n package, and they use template strings for their gettext function, but they do not require it to be passed to the constructor, thus requiring no modifications.
Do you think we should use it? We can do it by using inspect.currentframe().f_back.{f_locals|f_globals} (don't know if that's how they do it) to access the variables and extracting their valus.
Do you speak about doing things like that?
name = "Alice"
print(_("Hello {name}"))
I didn't like this non-explicit syntax, I prefer more verbose but explicit syntax :-)
Hey I think this PR is complete. The only thing missing is the tests, but that needs another language.
If you want I can add the pt_BR translation in this PR along with the tests. But I'm thinking I could add them in another PR.
So, I was writing the tests and found a problem: should we make the program reusable? What I mean is: currently, we can't run the program 2 times with different languages, because the LazyProxy (used in PROPERTY_NAMES and TYPES) gets cached with the first language. This shows up during tests because it gets cached to the language of the first test.
What we can do is: workaround it during test, or disable the cache for it.
Which one should we do?
Note: this only happens if we run it programatically, I don't know if this is supported and that's why I'm asking.
If you want I'll commit the tests with a pytest.mark.skip and add the .po file in another PR.
Also we are missing the precommits for make extract and make update (I think both should run in pre-commit).
Can you help with writing those? Maybe using make isn't good because it's not available by default in windows.
What we can do is: workaround it during test, or disable the cache for it.
Looks good :-)
Also we are missing the precommits for make extract and make update (I think both should run in pre-commit).
Can you help with writing those? ...
Yes, I can do this part :-)
What we can do is: workaround it during test, or disable the cache for it.
Looks good :-)
Sorry, which one should we do?
What we can do is: workaround it during test, or disable the cache for it.
Looks good :-)
Sorry, which one should we do?
By instinct disable the cache, but it's not a strong opinion :-)
I see. I think I'll just disable the cache since it's not a big speedup anyway.