[ooni-dev] ooni translations

[Aaron]

On Sun, Jun 23, 2013 at 11:47 AM, isis agora lovecruft
<isis at torproject.org>wrote:

> Aaron transcribed 5.1K bytes:
> > On Sun, Jun 23, 2013 at 12:15 AM, isis agora lovecruft
> > <isis at 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/ooni-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/ooni-dev/attachments/20130623/f8f360fe/attachment.html>