Add issue support configuration for OpenStreetMap on translatewiki.net about openstreetmap-website HOT 8 OPEN

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.

from openstreetmap-website.

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).

from openstreetmap-website.

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:

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.

from openstreetmap-website.

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.

from openstreetmap-website.

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)

from openstreetmap-website.

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.

from openstreetmap-website.

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

from openstreetmap-website.

This solution was implemented as a placeholder up until a suitable issue template for translation source strings is provided.

from openstreetmap-website.