tour: decide how to handle reports about errors in the tour translations

[ALTree]

There are like 20 bug reports about a few errors in the russian tour translation.

The problem is that we don't deploy or control the tour translations, and yet people keep opening issues that 1) we can't fix 2) the russian tour maintainer will never see; all because the "bug button" on the tour points here.

I don't know what a good way to handle issues in the tour translations would like. A couple ideas:

• We update the TRANSLATE document suggesting the translator to add a line in the welcome slide with his/her email address so that users can report translation problems, and maybe we suggest to disable the bug button. Then, reports about translation issues opened here will be just closed.

• We collect the contacts of the tour translators and then the tour maintainer can cc the translator when a new issue about a translation comes up. This could also be useful to alert that the translation must be re-deployed after an update to the official one. OTOH if the translator does not answer the call, we're stuck with a bug that we can't fix.

It seems like the 2nd option is what adg was planning to do, see comment here: golang/go#15693 (comment), but he's no longer the tour maintaner (and AFAIK he's no longer active in the golang/go project), so I'm not sure how to handle this. I don't even know if it would be possible to actually find out who the translation maintaners are.

[shuLhan]

Another option, any translation must have change the github-repo value [1] reference to their own repository. So, when user click "Bug" button at top right menu, user will redirect to translation repository, not the main (english) repository.

[1] https://github.com/golang/tour/blob/master/static/js/values.js#L52

[shuLhan]

I collect the translation statuses [1] and report an issues to some repositories. I hope this can be helpful.

[1] https://docs.google.com/document/d/1r6qYP9xey-u0vKXD8xxNaTWn-f_0WI1CtoDm0trx8ZQ/edit?usp=sharing

[ALTree]

@andybons can you help deciding a policy for this?

[andybons]

The bug link for a service not controlled by us should not point to the golang/go issue tracker since, as stated above, there’s nothing we can do about it. We should strongly encourage people who want to run their own instances to set up their own issue trackers in addition to collecting their info so that we can contact them should an issue be filed here.

[ALTree]

So as suggested above, we'll close issues about the translations (since we don't deploy or control them) and encourage the reporter to report the issue in the correct tracker.

Issue #1039 has an updated list of translations and their repo. Closing here.