Missing link from resource to translated community name?

[gravitystorm]

I'm opening this here for additional visibility, and the original issue is open over on the openstreetmap-website repository at openstreetmap/openstreetmap-website#3814

I'm unable to figure out how to get the translated name for a resource, when the translation uses fallbacks based on the resource type.

For example, given the fr-chapter resource, I can look up the fr-chapter entry in i18n/pl.yml.

pl:
  fr-chapter:
    description: Pomagamy rozwijać i ulepszać OpenStreetMap we Francji.

There is no name: there, so I then look up the translation defaults for the resource type in order to determine the fallback string - i.e. pl._defaults.osm-lc. This gives

pl:
  _defaults:
    osm-lc:
      name: '{community}'

Finally, and this is where I get stuck, I need to know which community to put in there. I mean, I personally know that it's supposed to be pl._communities.openstreetmapfrance: OpenStreetMap Francja. However, I can't find any link - either in the translations file or in any resources file - that has the mapping from fr-chapter -> openstreetmapfrance.

Any guidance would be greatly appreciated!

[1ec5]

If I’m not mistaken:

osm-community-index/lib/resolve_strings.js

Lines 36 to 39 in d31da8c

	if (itemStrings.community) {
	const communityID = simplify(itemStrings.community);
	itemStrings.community = localizerFn(`_communities.${communityID}`);
	}

osm-community-index/resources/europe/france/fr-chapter.json

Line 8 in d31da8c

"community": "OpenStreetMap France",

osm-community-index/lib/simplify.js

Lines 3 to 5 in d31da8c

	// remove spaces, punctuation, diacritics
	// for punction see https://stackoverflow.com/a/21224179
	export function simplify(str) {

[gravitystorm]

Right, got you. I really didn't expect the translation key to be derived from a string value like that!

Thanks for the insight.

[gravitystorm]

Oh, I should have asked before I closed this - would you contemplate changing how these lookups work? Or is there a technical reason with the translation system for keeping it like this?

I find that deriving the lookup key from a string is unexpected! Is there any reason not to have the translation lookup key explicitly within the resource?

It also means that projects that are using the osm-community-index information in a different language (e.g. over on openstreetmap-website) need to reimplement (and maintain, and follow any upstream changes to) both the simplify function and also the diacritics module, to make sure that we are matching the process to convert the string into the key. Would another option be for this conversion to be done once and explicit keys used in the resource instead?

[1ec5]

At a glance, explicitly defining the lookup key would make sense to me, even if it would require a little more work to populate those keys. However, maybe @bhousel knows of other considerations.

[bhousel]

I guess most of the context is on #30 (comment) and the comments after that one. We had wanted for a while to use default strings and some method of putting strings together to make less work for our volunteer translators.

So yeah, I'm ok with changing it so that we store the generated communityID with the resource, then consumers don't need to generate it at runtime.

[atomoil]

hey! I am up for picking this up, as I'd rather it was done in this project than re-implemented in the osm website's code. @bhousel can you give me any hints or tips on where in the code to add this, please?

[gravitystorm]

I think this will depend on how the maintainers want it to be implemented, and the main choice is whether the attribute should be generated in just the output files (i.e. dist/resources.*) or also included in the source files (under resources/). For our purposes, adding the attribute only in the dist files would be fine, and it's easier to implement that way too.

I'd look at adding a communityID attribute to the code somewhere around:

osm-community-index/scripts/build_index.js

Line 241 in 8ffdb28

if (item.strings.community) { obj.strings.community = item.strings.community; }

Of course, the maintainers might have a better approach in mind!

[bhousel]

I'd look at adding a communityID attribute to the code somewhere around:

☝️ I did this..
Now the build script saves the generated communityID alongside the community string.
This new attribute is persisted in all the resources/* files, and also in the dist/resources.* files too.

[gravitystorm]

@bhousel Thank you!

[atomoil]

Amazing, thank you @bhousel 🤩