Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reusing translations from other projects? #306

Open
nrenner opened this issue Jun 8, 2020 · 4 comments
Open

Reusing translations from other projects? #306

nrenner opened this issue Jun 8, 2020 · 4 comments
Labels

Comments

@nrenner
Copy link
Owner

nrenner commented Jun 8, 2020

PR #304 introduces dynamic translations of highway, surface and smoothness tag values. Some with underscore were added manually to the en.json and got removed by i18next:

brouter-web/locales/en.json

Lines 196 to 207 in f37489c

"data": {
"highway": {
"living_street": "Living Street"
},
"surface": {
"fine_gravel": "Fine Gravel",
"paving_stones": "Paving Stones"
},
"smoothness": {
"very_bad": "Very Bad"
}
}

They would need to be added to keys.js, but I left them off for now, as I think we should not translate them ourselves, but ideally reuse existing translations, some OSM editor must already have those.

On Transifex we are in the OpenStreetMap organisation, and e.g. the Vespucci editor is also part of that.

Can translations be shared between projects on Transifex (haven't done any research yet)?

@nrenner
Copy link
Owner Author

nrenner commented Jun 23, 2020

The concepts for reusing translations on Transifex I found are Sharing Translation Memory and Glossary. These are presented as suggestions, so still invole translators. Translation Memory also allows to automatically translate matching texts, but I'm a bit sceptical about that.

I haven't found anything that would allow to reference or link to specific translation keys from other projects.

i18next has the concept of Namespaces to load from separate files.

So my idea would be extract the required keys directly from the translation files of another project into separate files and not go through Transifex.

Some candidates are:

¹ smoothness shares some values with trail_visibility (has direct value translations), but not very_bad, very_horrible and impassable

None of the candidates is ideal, other ideas?

edit: iD presets moved to id-tagging-schema repo

@Bibi56
Copy link

Bibi56 commented Aug 18, 2020

None of the candidates is ideal, other ideas?

Don't parse the wiki, use the corresponding Data Items?

@nrenner
Copy link
Owner Author

nrenner commented Aug 18, 2020

Thanks for the hint, Data Items would be better than parsing, but probably depends on coverage.

The general problem with the wiki is, that there often are no explicit, single-word translations of the values, only descriptions. E.g. the Template:DE:Map Features:surface page has value translations only as bold highlight within the description. And the data items only sometimes seem to have a tag translation, e.g. surface=sett.

@Bibi56
Copy link

Bibi56 commented Aug 18, 2020

You're right: it depends on coverage but if we start to use it more, the coverage will get improved. If somebody is missing a translation he/she can improve the Wiki. Way easier than to translate in many tools in many formats.
Yes, some people destroyed some wiki pages for values as the values were in the main page... it would have been better to keep them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants