On Sun, Jun 23, 2013 at 11:47 AM, isis agora lovecruft <isis@torproject.org> wrote:
Aaron transcribed 5.1K bytes:
> On Sun, Jun 23, 2013 at 12:15 AM, isis agora lovecruft
> <isis@torproject.org>wrote:
>
> > Our code, from what I understand, though I have never worked with
> > Transifex or
> > any of these other translation services, is not particularly well-suited to
> > translation.
> >
>
> Could you clarify or provide an example of a project that is well-suited to
> translation?
>

Most projects store message strings as variables somewhere, and then whatever
the thing is that is giving displaying the message always asks for FOO_STRING,
where FOO_STRING might be in Arabic or Cantonese, etc.

Does this really work that well? BridgeDB used to keep strings in a file called I18n.py, and I recall it being pretty painful to work with.

>
> > First question, at what point/release is OONI going to aim for for having
> > translations available?
> >
>
> We have not set a target for translations of OONI.
>
>
> > Going with the "usual" route of having a strings.py seems like it wouldn't
> > work for OONI, do to the number of merge conflicts it would create (i.e.
> > if I
> > work on a nettest, and Aaron does some work on the director, and we both
> > change strings.py, then the merge might not work cleanly). Are there any
> > other
> > opinions or ideas on the cleanest way to get ready for translations?
> >
>
> Do you mean, translations of user-facing interfaces? Or all code
> documentation? Or OONI specification? Or OONI debug log messages?
>
> We have a lot of translation tasks. Which should take priority?
>

IMO, priority levels:

  1) translations of user-facing interfaces

  2) (maybe) debug log messages, but not really. I would assume the usual
  software engineering anglocentrism is permissible, and it would be way too
  many hours to do all of that. (and probably a bit unmaintainable)

So really just #1.
Well, I'd start with #1 and see what the community feedback is. The user-interface stuff includes command-line and http. The http ui is probably going to be fairly easy to translate because we can probably extract coherent paragraphs of text whereas the sort of snippets you get from extracting strings from the source code or strings files tends to be more fragmented and harder to translate.

>
> > We could have an ooni.strings submodule, and stick per file things in
> > there,
> > like director_str.py, etc. Thoughts?
> >
>
> I don't think I understand. What about using gettext and babel? You can
> extract strings from python source and templates directly, and these tools
> integrate with transifex.
>

Hmm. As I said, I have never done translation work. You use gettext in
BridgeDB, right? Do you have any suggestions for things that need to be done
to make translations (whenever we get to that point) less painful?

Well, it's pretty straightforward, actually. Just take a look at BridgeDB's templates and gettext usage. The setup.py, setup.cfg and accompanying README show how to set up pybabel for your project, and then you just need to wrap the strings you want to extract or return translated versions of by wrapping with the gettext function _(). At run-time you need a bit of code to set the corresponding language, and voila!
 

--
 ♥Ⓐ isis agora lovecruft
_________________________________________________________
GPG: 4096R/A3ADB67A2CDB8B35
Current Keys: https://blog.patternsinthevoid.net/isis.txt
_______________________________________________
ooni-dev mailing list
ooni-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/ooni-dev