[tor-bugs] #9959 [BridgeDB]: BridgeDB seems to be missing English translations
Tor Bug Tracker & Wiki
blackhole at torproject.org
Fri Oct 11 06:40:50 UTC 2013
#9959: BridgeDB seems to be missing English translations
-------------------------+-------------------------------------------------
Reporter: isis | Owner: isis
Type: defect | Status: new
Priority: blocker | Milestone:
Component: | Version:
BridgeDB | Keywords: bridgedb-ui, bridgedb-translations,
Resolution: | translations, bridgedb-https
Actual Points: | Parent ID:
Points: |
-------------------------+-------------------------------------------------
Comment (by aagbsn):
Hi Isis --
the default language is English, see: lib/bridgedb/I18n.py:6, which IIRC
simply doesn't replace any strings (that is, it defaults to the original
text) if the specified language is not found.
I'd be glad to help you understand how the .pot/.po/.mo file work
Firstly, all the templates (html) and code (py) files have some syntactic
sugar wrapping any strings that you want to translate. It looks like _("A
String I Want To Translate").
The second thing you do is extract all of the above such strings and dump
them into a .pot file. pybabel provides a set of message extractors, and
these are added to setup.py along with a set of paths (message_extractors)
that tell pybabel what sort of files it should hunt for strings in.
when you invoke extract_messages" pybabel will automagically output a .pot
file inside the project path under
projectname/i18n/templates/projectname.pot (this path is static, I guess
pybabel could use a patch if you want to change it).
For each language you want to get a translation for, you need to
init_catalog -l LANG for each of those languages. That will generate an
untranslated .po file in the appropriate path. You're going to replace
that file anyway with the one that transifex produces, though.
The .pot template file is handed off to transifex/pootle/hand edited, and
a set of corresponding .po files are produced, one for each translation.
If you take a look at each of the files, you'll see they correspond to the
template (remember, you should always redo the extract_messages command
any time you add new strings for translation), where each extracted string
has has the original string followed by the translated string. After these
files are merged into the appropriate path (see init_catalog), you just
need to compile the catalog to produce a binary format (.mo) that works
with gettext to efficiently look up the translated string.
At runtime, you figure out what locale the user wants (in BridgeDB see
HTTPServer.py setLocaleFromRequestHeader) and tell gettext which language
you want to translate for (lang.install()). Then, whenver the _() wrapper
is encountered, gettext goes off and searches the corresponding .mo file
(you did update it all the messages, and reinstall BridgeDB to put all the
.mo files in the right paths, right?) to find the matching string and
returns that instead of the original text.
Hopefully this makes it a bit clearer what is going on. If you're having
troubles with English missing some of the time, dump the output of the
expected locale to a debug log and make sure it is set to None or "en" so
that the default (untranslated) locale will be returned. It could be that
BridgeDB isn't setting the locale properly in some context (global state +
twisted async madness? who knows..). If English is always missing, git
bisect is your friend :)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9959#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list