Closed jholdstock closed 1 year ago
I think it will be easier to navigate and manage languages when all files for language X are in src/content/X
. In terms of Git it also allows to track all changes to language X with git log -- src/content/X
.
Will Hugo allow to move transifex_catalogs/X.json
to src/content/X/strings.json
and is it a good idea?
And I wonder why add src/content/X
to .gitignore
, shouldn't they be available for potential translations of content in en
?
The changes in this PR are just for files generated during the build process, and wont effect workflow for translators or developers at all. If you look at the files changed, the only deleted files are completely empty and no actual i18n content has been touched.
Its a weird quirk of Hugo. Fallback to English for missing translations isnt a native feature, and hacking it in requires creating a whole bunch of empty files. This PR is basically just enabling those empty files to be generated automatically rather than having them tracked in version control.
Will Hugo allow to move transifex_catalogs/X.json to src/content/X/strings.json and is it a good idea?
The translator.html tool which was inherited from decrediton is currently tied to the format of the transifex_catalogs/X.json
files. Once we have translations (mostly) done for the new website, I plan to completely remove the transifex stuff, which will include moving strings in to the src/
dir as you suggest.
Do i18n on a per-dir basis rather than per-file. For more info see https://gohugo.io/content-management/multilingual/#translate-your-content
Using sub-directories allows us to remove over 100 empty i18n files from version control, and instead just copy the en directory at build time.
This also fixes an issue where press releases were not displayed in non-en languages. (Closes #1071)