Re: [tor-bugs] #9959 [BridgeDB]: BridgeDB seems to be missing English translations

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#9959: BridgeDB seems to be missing English translations
-------------------------+-------------------------------------------------
     Reporter:  isis     |      Owner:  isis
         Type:  defect   |     Status:  needs_review
     Priority:  blocker  |  Milestone:
    Component:           |    Version:
  BridgeDB               |   Keywords:  bridgedb-ui, bridgedb-translations,
   Resolution:           |  translations, bridgedb-https
Actual Points:           |  Parent ID:
       Points:           |
-------------------------+-------------------------------------------------

Comment (by aagbsn):

 Replying to [comment:2 isis]:
 > Replying to [comment:1 aagbsn]:
 > > Hi Isis --
 >
 > Hey aagbsn! Thanks for helping!
 >
 > > 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.
 >
 > Alright. At least I'm not going crazier. I was worried for a minute that
 there had always been English "translations" and that I must have somehow
 deleted them and obscured that from myself in the git history.
 >
 > > 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").
 >
 > First, it's fixed already, in
 [https://gitweb.torproject.org/user/isis/bridgedb.git/shortlog/refs/heads/feature/9959
 -pas-danglais my branch feature/9959-pas-danglais]. All of the
 .pot/.po/.mo stuff I ''think'' that I've already understood (I rewrote the
 README months ago, so it now includes detailed instructions for dealing
 with all that).
 >
 > Two things however, when I was working this out are now marked XXX in
 the README:
 > {{{
 > [xxx outdated, these commands seem to not exist...]
 >
 >      python setup.py trans && python setup.py install_data
 > }}}

 I believe these were how we did translation before, and install_data
 points at the method installData in setup.py that is made redundant by the
 package_data directive in setup().

 >
 > I'm not sure what `trans` was supposed to do, nor can I find reference
 to a distutils command class anywhere for that, so I assumed it was
 something from an old python gettext-ish module that was removed/replaced
 at some point.

 I think that sounds accurate.

 >
 > `install_data` doesn't do anything (even though the command class for it
 is present) because modern versions of setuptools now handle installing
 data files in the .egg through the pkg_resources API. I should probably
 just remove both of these, but I didn't know what `trans` was so I left it
 hanging out.
 >

 I think you can drop it and keep only the commands that are necessary for
 translating and installing BridgeDB.

 > > 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 :)
 >
 > Hrm. I fixed it by creating "untranslated" .po files for `en`, `en_GB`
 and `en_US`. Which seems like madness to me, and I can't for the life of
 me (I already bisected twice) figure out why BridgeDB all of a sudden
 wants translation files for English. But it's working again at least.

 Well, sounds like that will work. Were translations broken even after you
 rolled back to a prior commit and did a clean install?

 >
 > One strange thing that I noticed, if you look at
 [https://trac.torproject.org/projects/tor/ticket/9157#comment:19 my
 comment on #9517] which links to this ticket, is that all of the languages
 in the `Accept-Language` header have a `q` weight assigned to them -- all
 except for `en`, the first one. I had assumed that this was an implied
 `en;q=1` meaning "primary preference"...but maybe it just wasn't ever
 assigned a weight at all. If that is the case...beetlejuice, that bug
 could be anywhere...in BridgeDB, in Twisted, in Firefox, in pybabel...ugh.
 But it's fixed so "no happy; be worry" as they always say, right?

 Hm, how many languages are present in your Accept-Language header?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9959#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs