Opened 9 years ago

Closed 9 years ago

Last modified 8 years ago

#1613 closed task (implemented)

i18n bridgedb

Reported by: phobos Owned by: kaner
Priority: Medium Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: #4380 Points:
Reviewer: Sponsor:

Description

i18n bridgedb

Child Tickets

Change History (12)

comment:1 Changed 9 years ago by phobos

Component: Tor - DistributionTor - BridgeDB

comment:2 Changed 9 years ago by kaner

Owner: set to kaner
Status: newassigned

comment:3 Changed 9 years ago by arma

Is this a duplicate of #1609?

If not, how does it differ?

comment:4 Changed 9 years ago by kaner

Status: assignedneeds_review

comment:5 Changed 9 years ago by kaner

Yes, it *is* a duplicate of #1609, so I closed that.

comment:6 Changed 9 years ago by nickm

Looking through the code for initial issues:

  • Having to list all the languages explicitly in the configuration file seems awkward. Can't we load a list by just seeing what languages are available?
  • This HTML_1...HTML_5 and EMAIL_1...EMAIL_6 business seems kinda awkward. Is there a reason to split things up into 5 (or 6) numbered pieces?
  • I'm afraid I don't understand what's going on with gettext here. It looks like you mess with global state somehow by calling the .install() method on every language you're about to send before you generate any messages. Using global state like this makes me twitchy; is there really no way to make this more OO and ask the I18N module for some kind of "Translation" object, then ask the translation object for an approprate "_" method?

comment:7 Changed 9 years ago by kaner

Thanks for reviewing.

1.) As an alternative to configuring available languages, we could also iterate through the i18n directory, see what's there and add that to the pool of available languages. But a) as far as i understood our Pootle process, we pull in all possible languages into that directory and wait for poeple to translate things. That means we'd have a large percentage of unusable languages for a good while and a small percentage of unusable languages for a long while. Also, b) if we learn available languages in an automated way from the i18n directory, we can't disable a certain language for a certain time (for whatever reason, we've had that case in GetTor). It's obviously much easier to do that via config. Also, c) is it really so awkward?

2.) Yes. I agree that it is ugly. The idea is here that we can re-use certain chunks in other parts (Compare HTML_3 and EMAIL_4, for instance. Yes, I know this needs to be changed in the current code) and make it easier for Pootle users and Pootle itself. I've learned that both like smaller chunks better. I'm all ears (eyes?) for a more elegant way to do this.

3.) I agree on the global state itchyness. I'll look into it.

comment:8 Changed 9 years ago by nickm

1) a and b could be solved by having enabled/disabled be somehow attached to the languages themselves. I don't know our pootle process that well. It does seem, though, that trying to edit the configuration file to tell which languages are up-to-date is a bit of a losing proposition. Is there really no way to get only the translated languages?

2) A list beats a bunch of indexed variables. Lists are naturally iterable, joinable, resizeable, etc, whereas if you add or remove an entry from the bunch of indexed variables, you've got to change everything that uses them.

comment:9 in reply to:  8 Changed 9 years ago by kaner

Replying to nickm:

Thanks for your comment.

1) a and b could be solved by having enabled/disabled be somehow attached to the languages themselves. I don't know our pootle process that well. It does seem, though, that trying to edit the configuration file to tell which languages are up-to-date is a bit of a losing proposition. Is there really no way to get only the translated languages?

Ok, I just got rid of that whole bit. We now try our best to find a translation, if there is none, we fall back to english. No looping through the filesystem, no config file editing.

2) A list beats a bunch of indexed variables. Lists are naturally iterable, joinable, resizeable, etc, whereas if you add or remove an entry from the bunch of indexed variables, you've got to change everything that uses them.

Accepted, changed.

Also, 3) from your original comment is changed: No global Translation objects anymore.

The code is tested (https, email requests for different languages), pylint was run, the install procedure and README are adapted.

Please review and merge if possible.

comment:10 Changed 9 years ago by kaner

Added another tiny change requested by arma: Users should be able to request a certain language in their HTTP request via either /?lang=foo or /foo.

comment:11 Changed 9 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

Seems fine by me. merged

comment:12 Changed 8 years ago by karsten

Milestone: BridgeDB Upgrades Phase 1
Parent ID: #4380

Assigning as a child ticket to the project ticket that replaces the "BridgeDB Upgrades Phase 1" milestone.

Note: See TracTickets for help on using tickets.