Push only global ressources to transifex for translation

[manfredbrandl]

From https://github.com/osmlab/osm-community-index/blob/master/CONTRIBUTING.md :

All community resources automatically support localization of the name, description, and extendedDescription text. These fields should be written in US English.

Please push only global ressources to transifex to translate to all languages.
Other resources should not be pushed to transifex but translated by the local community.
It is not helpfull to translate community contact information to languages not spoken by the local community. I try to keep the German iD-Translation up to date and i would prefer to see "0 strings to translate" even if strings like "OSM Chattanooga" (Tennesee, less then 200k people) is not translated.

[bhousel]

My worry is that I wouldn't want a non-native-speaking mapper to see a wall of unreadable text after they save their edit in iD. Mockup of what I will probably build: openstreetmap/iD#4815 (comment)

I agree that these local strings are a lower priority than translating the country-wide community strings, but people do:

• armchair map
• live and map in a country where they speak a different language than official
• live and map in countries with multiple official languages

Is it really that much of an issue? I don't see there being more than a few hundred of these, and they wouldn't change often.

[manfredbrandl]

I did translate the whole "community" section to German, there are really many nearly identical descriptions. Maybe we can reduce Translation to the Name of the Area and the Languages spoken in the community there so that everybody knows where he mapped and if he can contact the community in a language she knows. Today community contains already more strings than imagery:

[manfredbrandl]

Today many new untranslated strings differ nearly only by the name of the country from each other. Is there a way to avoid repeated tranalation of nearly identical texts?

[bhousel]

Today many new untranslated strings differ nearly only by the name of the country from each other. Is there a way to avoid repeated translation of nearly identical texts?

I don't know, but I'm happy to consider suggestions on ways to make this easier for translators..

Even if we change this, you'd still have to translate something for each string right?
e.g. replacing "Talk-mg Mailing List" with a placeholder like "{whatever} Mailing List", you still need to provide a translation for the "Talk-mg" part.

[1ec5]

“talk-…” is unlocalizable anyways: you can change the interface language in Mailman, but that doesn’t affect the name of the mailing list.

[manfredbrandl]

Is it possible to allow translate "Mailing List" only once and use it like "Talk-mb {mailinglist}" or translate "Join the OpenStreetMap {1} Community on {2}" and separately translate "Afghanistan", "Albania" etc. and "Facebook", "Twitter" etc.?

[bhousel]

Yes @manfredbrandl good suggestion..
Maybe after this initial release, I can switch to having each type of community have a "default" entry that will have strings pieced together with tokens like you described.

Default Mailing List

name:  "{what} Mailing List",
description: "The official mailing list for {country}"
etc.

[matkoniecz]

Is it possible to allow translate "Mailing List" only once and use it like "Talk-mb {mailinglist}" or translate "Join the OpenStreetMap {1} Community on {2}" and separately translate "Afghanistan", "Albania" etc. and "Facebook", "Twitter" etc.?

Main problem for this approach is that some languages may have special rules for some sort of situation, and with single rule for all it would be no longer possible to correctly translate it.

[bhousel]

Main problem for this approach is that some languages may have special rules for some sort of situation, and with single rule for all it would be no longer possible to correctly translate it.

Can you be specific? I can't imagine a situation where we'd have trouble with a token replacement for the name of a mailing list of twitter feed. I don't think these are things that have inconsistent gender or pluralization where we need to be careful how a sentence gets pieced together.

cc @1ec5 , who knows way more about this than I do.

[matkoniecz]

For example:

Forum of OpenStreetMap community in Ukraine may be templated into Forum of OpenStreetMap community in {COUNTRY}

OpenStreetMap Ukraine Forum may be templated into OpenStreetMap {COUNTRY} Forum

But it would be Forum ukraińskiej społeczności OpenStreetMap and Forum OpenStreetMap Ukraina in Polish translation (ukraińskiej vs Ukraina).

---

There is in the Philippines vs in Spain (not sure whatever variation on English side is correct or necessary here) - but in Polish it certainly will na Filipinach w Hiszpani (na vs w).

[matkoniecz]

Overall, templating will take time and once translators from new languages will appear it will require more and more tweaks. Just Polish needs COUNTRY_POSSESSIVE in addition to COUNTRY. And LOCATION_PREPOSITION. And maybe other things - I just looked to find something problematic, I was not trying to design foolproof templating (because based on my limited experience it is sometimes feasible for English but fails horribly in Polish).

I suspect that it may be better to have translators copy and paste text that can be identical in their languages.

[matkoniecz]

Though "Follow us on Twitter at {url}" is repeated multiple times - maybe it is avoidable.

[bhousel]

I did some work to support default values..

• Default strings are a thing now - they can be found in defaults.json

• Source strings have moved to a strings object. (This lets us continue to have resolved name and description in the completeFeatureCollection.json file, which powers the map on https://openstreetmap.community ).

• These default string templates may start showing up on Transifex soon (tonight?)

• I tried really hard to keep things simple, knowing that different languages do not play nice with string token replacement.
  Please let me know if any of these default strings wont work in your language. (see examples below)

• I started removing all the redundant/duplicate strings. I've only done Africa so far, but will work my way around the world soon.

• This issue can stay open until we've removed the duplicates and tested things out to make sure translations are not too awkward or weird.

The contributing guide looks like this now:

---

strings

The strings object contains text strings that describe the community resource.
Strings should be supplied in US English, and they will be sent to Transifex for translation to other languages.

• community - (optional) Display name for the community (e.g. "OpenStreetMap Ethiopia")
• name - (optional) Display name for this community resource (e.g. "OpenStreetMap Ethiopia on Facebook")
• description - (optional) One line description of the community resource
• extendedDescription - (optional) Longer description of the community resource

Also, all string properties support the following replacement tokens:

• {account} - Will be replaced with the account value
  (e.g. "The {account} mailing list" -> "The talk-et mailing list")
• {community} - Will be replaced with the community value
  (e.g. "{community} on Facebook" -> "OpenStreetMap Ethiopia on Facebook")
• {url} - Will be replaced with the url value
  (e.g. "Visit {url} to learn more" -> "Visit http://example.com to learn more ")
• {signupUrl} - Will be replaced with the signupUrl value
  (e.g. "Signup at {signupUrl}" -> "Sign up at http://example.com ")

Many resource types support default string values found in defaults.json, for example:

"facebook": {
  "name": "{community} on Facebook",
  "description": "Join our community on Facebook"
},
"mailinglist": {
  "name": "{account} Mailing List",
  "description": "The official mailing list for {community}"
},
…

Although all string properties are optional, each resource must be able to resolve a name and description, either by specifying them directly or generating them from default values and replacement tokens.

[bhousel]

This is done! 🎉 Always fun to close a really old issue!

I spent a lot of time the past few days to add support for default strings and templates.

• This project uses templating pretty heavily now - contributors generally don't even need to supply urls for mailing lists or forums or meetups or any string we can generate from the defaults.
• ⚠️ completeFeatureCollection.json has changed slightly, and this will affect downstream projects that use it.
  The resolved strings are now in a resolved Object.
  • resource.name -> resource.resolved.name,
  • resource.url -> resource.resolved.url, etc.
• The number of strings to translate went from 1347 down to around 868 🎊 (I was able to do this without changing the existing string IDs, so strings that were already translated on Transifex should mostly stay that way).
• This will be a breaking change, so I'll release an official v4 soon, after we've finished the list in Missing communications channels #423
• I'll spend a day or so freshening up the project documentation too.

[jbelien]

Upgrade has been applied to https://community.osm.be/ ! 🚀

Awesome work @bhousel , that indeed makes all the resources way cleaner. 👍