Farsi translation uses arabic commas in 'terms'

[lonvia]

The Farsi translation of the presets consistently uses the arabic comma (U+060C) for separating 'terms'. Example: https://github.com/openstreetmap/id-tagging-schema/blob/1cbef5186feb17f599bd5df04aa99d581b0cb5b1/dist/translations/fa.json#L1197

Is this an error on the translation side or should software accept both normal and arabic comma as a separator?

[1ec5]

I’d be inclined to call it an error, but it probably wouldn’t hurt to add the Arabic comma as an alternative delimiter. Every project that uses this localizations (such as Go Map!!) would need to make the same change, even though the localizations are nominally part of the iD project.

This would be a good argument for replacing the comma with a newline as the standard delimiter. That would be consistent with aliases and also remove ambiguity as to whether a space is required after the comma. I think changing the delimiter would require a change to both iD and id-tagging-schema, if not also schema-builder.

[westnordost]

Changing it to newlines may be consistent (with aliases), though it would (unnecessarily) break backward compatibility.

IF backward compatibility is broken, I would suggest (instead) to change the build script(s) that create the files in dist to already return the terms and aliases as an array of strings instead of letting the clients (iD, osmfeatures, nominatim, Go Map!! etc...) deal with splitting the string (and removing any whitespaces around the terms etc.). However it is presented to translators on Transifex is then something that will be separate of this anyway.

If backward compatibility should not be broken, I'd suggest to at least let the build script deal with things like this.

I think breaking backward compatibility is not that big of a deal, after all, this project uses proper versioning and it has been broken a couple of times in the last years. (IIRC last time was when the brand presets were separated out from the generic iD presets but I may be mistaken)