My understanding of the discussions about i18n during the past two weeks is that the SecureDrop team is willing to add i18n as soon as possible. They are however focused on publishing the 0.4 release which is going to feature freeze after the last pending PRs are merged. It means the release/0.4 branch will be created next week and we can start sending i18n pull requests against the develop branch without disturbing the stable release.
Since the SecureDrop team attention won’t be focused on i18n and their bandwidth will be limited, we (as a community), need a strategy to avoid wasting good work. This is not a problem specific to SecureDrop, it is pretty much the same with every project when trying to introduce a significant change that is not the top priority of the core team driving the development.
I think it would be enough to make progress as follows:
create a topic branch for i18n with a patch series made of minimal commit, each passing the CI
work with this topic branch to provide translations in at least one language
send a PR for the first commit in the patch series and wait for the SecureDrop team to merge it on their own time. And submit again, one commit, when it is merged.
rebase at least once a day the patch series so it stays up to date with the develop branch
I realize this is more work on our part (us the community but we’re not the bottleneck and there are many of us. I don’t mind if things take a very long time to land upstream, as long as we have a strategy ensuring it does not go to waste.
Using the same method as phpmyadmin the SecureDrop documentation can also be translated via weblate so it is all in the same place (website strings and localized documentation). Not sure I understand how they do it just yet but it looks simple.
I see you manually parsed the Accept-Language. At least there is no complicated match going on and problems are easier to diagnose
As a first minimal step to load the locale, I used best_match. I’ll most likely revert to your method if it gives me trouble. The user has no control over it, this is very limited. I did not want to merge the commit focusing on loading the locale with the commit that implements a user interface to select the language (via query arguments or via a select in the HTML page).
Also, instead of explicitly listing the locales in the config file, I chose to only define LOCALE which set the default. The list of available locales is defined by exploring the content of the translations directory. My motivation was primarily to reduce the change of config.py.example to the strict minimum because it needs to be carefully upgraded / verified. If there was a list of available locales, including human readable labels, it would make it more complicated. Both can be defined elsewhere (the human readable strings are part of the GUI, the list of available translations can be read from the directory, restricting the list of translations displayed to the user can also be part of the GUI configuration).
This is not carved in stone, reason why I did not elaborate more in the commit messages. Please let me know if you have concerns
Yes, but you’d want to have a mapping of en_US to English (American) or whatever for the buttons a user clicks. Don’t put that in config.py, but somewhere else that’s hard coded. The app I pulled it from had a config.py that is totally unlike what SD uses.
The next step is to go over each source/template file and gettextize it. It may be good to l10n in parallel, just to see how manageable the fixed size font / layout is and what compromises it requires. It would be better to run into blockers before all files are processed. Since @heartsucker already did the work for German not too long ago I’m not very worried.
git pull wip-i18n-test # which is where weblate merges the translated .po
./manage.py translate --compile # on the development VM
navigate to manually check the strings do not break the layout
and repeat until it’s done. In firefox Preference -> Content -> Languages can be used to select the language by moving the prefered language in front of the list. It changes the Accept-Language header accordingly and source/journalist pages will respond to the change on every request.