Hi!
Lunar wrote (31 Mar 2015 10:15:27 GMT) :
> intrigeri:
>> OK, I see. Let's try to define the problem better before we jump to
>> candidate solutions.
[...]
> There's another use case that I can think of:
Thanks!
> * Letting translators report about problems in original strings.
> Sometimes translators will spot a typo, be unable to translate
> ambiguous strings (missing comment), or be unable to do a meaningful
> translations because of how strings are split or formatted.
> I think it's worthwhile to smooth the process as much as possible of
> reporting such problems.
Totally agreed -- this would qualify as a MAY for me: I think we'll
expect website translators to read a bit of documentation about the
process, style etc. anyway, so worst case that piece of doc can
explain how to report issues in the original English text.
Now, I'm wary of having one more bug tracker to manage (be it as
admins of the webapp, or on the sysadmin side of things), and one more
bug tracker interface to get accustomed with (for translators
themselves: I'm assuming that most people who would be able and
willing to commit to do good translations of our website on the
long-term, will be/become kind of Tails power users, and will learn
a little bit of WhisperBack and/or Redmine at some point).
So I'd rather not have an *integrated* bug tracker in the translation
platform. And then, perhaps the best of both worlds would be to
interface somehow the translation platform with our existing bug
reporting tools?
E.g. we may want a "Report a problem in the original English text"
button, that either results in an email being sent to -l10n@
or -support-private@ (KISS!), or links to the Redmine ticket creation
form (needs an account there, so probably it's too painful for
translators).
Cheers,
--
intrigeri
