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.
First question, at what point/release is OONI going to aim for for having translations available?
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?
We could have an ooni.strings submodule, and stick per file things in there, like director_str.py, etc. Thoughts?
On Sun, Jun 23, 2013 at 12:15 AM, isis agora lovecruft isis@torproject.orgwrote:
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?
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?
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.
--Aaron
--
♥Ⓐ 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
Aaron transcribed 5.1K bytes:
On Sun, Jun 23, 2013 at 12:15 AM, isis agora lovecruft isis@torproject.orgwrote:
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.
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.
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?
On Sun, Jun 23, 2013 at 11:47 AM, isis agora lovecruft isis@torproject.orgwrote:
Aaron transcribed 5.1K bytes:
On Sun, Jun 23, 2013 at 12:15 AM, isis agora lovecruft isis@torproject.orgwrote:
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:
translations of user-facing interfaces
(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
-
Aaron -
Aaron -
isis agora lovecruft