Add issue support configuration for OpenStreetMap on translatewiki.net

[wangombe-g]

Problem

At the moment, https://translatewiki.net/w/i.php?title=Translating_talk:OpenStreetMap is configured as the support page for OSM translation string issues on https://translatewiki.net. However, this page seems not to receive attention.

Description

CC: @translatewiki follow-up for phabricator task: T357386

I work with the Language Team at Wikimedia Foundation and we would like to suggest a template be configured on Github issues for translation message issues that may occur during localization efforts emanating from https://translatewiki.net. As mentioned in the problem statement, these issue are currently going unaddressed which may impact the quality of localized strings for OSM.

Perhaps posting these translation message issue on Github would be ideal for visibility. At the moment, we have an open PR (patch) on Gerrit which basically proposes adding translation message issues to Github using the bug and i18n label. This may not be the most optimal solution. An issue template would be ideal.

Screenshots

No response

[gravitystorm]

I think the key issue is to make sure that as much of the translation queries that can be dealt with by our community at translatewiki are dealt with there. For example, if there's questions like "what should the spanish translation be for 'Relation'" or "I don't agree with this translation in German" then that's something that should be asked and answered within the translatewiki community, since here we are mostly programmers who don't have any good answers for that kind of thing. Very few, if any, of the translators are active here on this repo, so I think there's even less chance for many of the queries to be answered.

If there's a situation were something needs to change in our codebase to help support translators (e.g. avoid using zero: key) then that's definitely something for here.

I've looked through the linked page, and it would be very hard for us to deal with many of the comments there. (I'm also not sure how to reply to most of those, even if I wanted to, since some parts of the page have "Reply" links and others don't, but that's a different problem).

[wangombe-g]

I can acknowledge that there are language specific issues on the Translatewiki OSM support page that should be answered by the translation community. Issues with the locale strings, however, are the responsibility of the developer and not the translations community. For instance, the developer is responsible for addressing this issue where there is a broken link by updating en.yml:L2105 to an existing link.

The green box represents the language the translator was translating into.

Translslatewiki, using the yml file format which OSM is configured to use for localization, typically represents nesting using a period, i.e ".". For example, in the screenshot above, the string in question is located in the file en.yml:L3103: where the strings follow a hierarchy in OSM like so:

javascripts
	map
		base
			tracestracktop_top

In this screenshot, the translator is asking that the word 'doesn't' located here en.yml:L2418, be considered for revision as it may not translate well to Turkish or other languages.

Here is a link to Translatewiki message documentation which describes how translation source strings should be structured and how describing them can aid translators in understating context. A majority of these issues are also in regard to context.

[Nikerabbit]

In case you would get language specific questions here, we can see how we can improve the user interface in our side to better redirect language specific topics to our language portals.

[Nikerabbit]

Circling back to this, do you feel comfortable for making a decision to unblock us? For example:

• Yes, we can direct questions to here and monitor whether the questions are in scope. If too many are out of scope, revert the change until further improvements are made
• No, keep pointing questions on the talk page (and have someone from OSM watch that page to comment on relevant questions)

[tordans]

From what I understand, one category of issues are non-ideal translation keys that are specified inside the code. I am thinking about cases like https://github.com/openstreetmap/openstreetmap-website/pull/4602/files and …

In this screenshot, the translator is asking that the word 'doesn't' located here en.yml:L2418, be considered for revision as it may not translate well to Turkish or other languages.

For those cases, we could create a specific issue template (code example) like the first two on https://github.com/openstreetmap/openstreetmap-website/issues/new/choose.

Ideally, translators would have docs somewhere in translatewiki that explain this specific use case and from there link directly into the issue template.

[wangombe-g]

I think this approach is viable; that is, creating an issue template for translation source strings. Alternatively, you could specify an existing template that we can use to highlight source string issues.

[wangombe-g]

Hi @tordans, it's not clear which option above you reacted to with the 👍.