Translating talk:OpenStreetMap/LiquidThreads

This page contains archived discussions using the Liquid Threads extension. You can still participate in existing conversations, but you should start new conversations using the new discussion tools on the main talk page.

How can I add more plural variants? I can only write "1 point", "2 points", "few points" and "many points", however my language has specific variants for "3" and "4 points", how can I resolve this problem?

See https://unicode-org.github.io/cldr-staging/charts/37/supplemental/language_plural_rules.html#br Maro21 (talk) 12:16, 2 April 2023 (UTC)

The reference to CLDR was not sufficient to solve the problem in OSM, as it still does not accept to distinguish all plural classifiers: "one", "two", "few". The rules are similar to other Celtic languages (also in Slavic languages like Russian):

• the "one" classifer on Breton is its singular, which covers 1, 21, 31..., 101...
• the "two" classifier in Breton is its dual, which covers 2, 22, 32, ..., 102...
• the "few" classifier in Breton is its paucal, which covers 3, 4, 9, 23, 23, 29, 33, 34, 39..., 103, 104, 109, ...
• the "many" classifier in Breton is for some large plurals, which covers multiples of 1 million
• the "other" classifier is the generic plural, which covers 0, 5-8, 10-20, 30, 40, ..., 100, 110, ..., 200, ..., 1000... (No need for a "zero" classifier as it is the same as the Breton plural).

  Note: Semitic languages like Arabic require supporting 6 classifiers, adding the "zero" classifier.

All these 5 classifiers require displaying the actual value in the variable (e.g. "one" is not just 1), however the OSM plural support does NOT pass any explicit variable in its "PLURAL" syntax, meaning that you cannot translate messages needing several distinct plural classes, without creating "patchwork" messages (which complicates translation, especially when there are mutations between sucessive words and creating patchwork messages also assumes an incorrect ordering of parts of sentences.

If we want to specialize zero for translating an absence by a negation (instead of using a generic plural with the actual value), we need a numeric override (but it is not supported by the OSM syntax, only by the MediaWiki syntax). The same is true if we want to specialize translations for 1, 2, or for spelling some values (e.g. all integers from 1 to 19) instead of noting them numerically.

This message and several others are no longer translatable because Translatewiki.net now enforces CLDR plural rules on the {{PLURAL}} syntax. As in MediaWiki, translators need to be able to specify zero and one cases even if the language does not inflect the noun differently. Like many software projects, including MediaWiki, messages sometimes customize the zero rule to say something more natural than "0 foos", such as "No foos". This is especially important to languages like Vietnamese that are less flexible than English about the use of "zero" and "no" in a sentence. For example, the equivalent of "You have 0 messages" would be ungrammatical in Vietnamese; it must be phrased as "You don't have any messages". (Additionally, CLDR has incorrect data on Vietnamese plural rules, but the fix has been delayed for years.)

If it isn't feasible to override CLDR's incorrect plural rules or carve out an exception for zero and one, then the plural error checking should be disabled for Vietnamese. Until CLDR is fixed, this may mean that a software project using CLDR for pluralization would wind up with messages it can't access, but that would be better than the current situation, where translators are unable to even contribute translations at all.

This is a commonly known issue :)
See

• https://github.com/openstreetmap/openstreetmap-website/issues/3997
• Support#I can't upload correct translation
• Support#"zero" in OpenStreetMap
• https://translatewiki.net/w/i.php?title=Thread:Translating_talk:OpenStreetMap/About_Osm:Issues.show.reports/pt&lqt_method=thread_history
• https://translatewiki.net/w/i.php?title=Thread:Translating_talk:OpenStreetMap/Osm:Issues.show.reports/en_cannot_be_translated_correctly&lqt_method=thread_history
• https://translatewiki.net/w/i.php?title=Thread:Translating_talk:OpenStreetMap/About_Osm:Diary_entries.diary_entry.comment_count/sc&lqt_method=thread_history
• https://translatewiki.net/w/i.php?title=Thread:Translating_talk:OpenStreetMap/About_Osm:Issues.show.reports/uk&lqt_method=thread_history
• https://translatewiki.net/w/i.php?title=Thread:Translating_talk:OpenStreetMap/About_Osm:Traces.trace.count_points/br_(2)&lqt_method=thread_history
• First report, 22 Feb 2022: https://translatewiki.net/w/i.php?title=Thread:Translating_talk:OpenStreetMap/About_Osm:Issues.show.reports/nl&lqt_method=thread_history

There is something wrong with validation of pluralization. `zero=` parameter is claimed as invalid.

I also came across this issue translating Issues.show.reports into Danish yesterday. There are multiple threads in Discussion about this which are somewhat technical and speculative as to how this should be handled. See also the website Github issue #3997 for further details.

But there are no advise to how translators should handle the current situation where plural translations, in forms which were previously submitted, are rejected.

For Danish I had to remove the "zero" translation which let me publish the translation with a "one" and default/multiple translation. As I understand it this will fallback to the default translation for 0, which for Danish would be correct (but not as good as having a correctly worded zero translation ).

Most strings under Osm:Auth.providers shouldn't be up for translation. Brand names like Facebook, Google and GitHub are deliberately not localised. Wikipedia is rendered differently in other languages but the others should be removed. Also, Windows Live no longer exists, it's now called Outlook for that type of account.

It's not true that in all languages "Google" is "Google." In most it is, but not in all. See translations:

• Osm:Auth.providers.none (not a brand name)
• Osm:Auth.providers.wikipedia (localized per local community decision)
• Osm:Auth.providers.facebook (but see https://about.meta.com/brand/resources/meta/our-trademarks/)
• Osm:Auth.providers.google (but see https://about.google/brand-resource-center/trademark-list/)
• Osm:Auth.providers.github (but see https://github.com/logos)
• Osm:Auth.providers.openid (but see https://openid.net/wordpress-content/uploads/2017/06/OIDF-Policy-Trademark-Usage-Policy-Final-6-19-2017.pdf)
• Osm:Auth.providers.windowslive (but see https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks)

Citing brands normally requires a (R) or (TM) symbol in plain text, but the capitalization is not erlevant for domain names (that are only reserved for the time they are registered and renewed with the proper fees paid to the registrar). If we want to make sure we link to these brand names, there are generally rules so that any third party may not use these brands prominently when they should instead make thir own party party name and logo more visible if the content does not originates and is not protected by the brand's copyright. Site links using these brands just need to not use a sentence which may visitors think that, for example a third party page hosted on these services are endorsed by these brands. Using logos is more restricted (and it is not allowed to change colors, and there are placement/layout restrictions). For simple text, it is acceptable to "translate" (or transliterate) these as long as there's no (R) to (tm) symbol beside it, and that needed adaptations (including voice rendering which is very variable across spoken languages) which can more clearly cite the brand are also explained by something more explicit and using the branding rules (generally a logo, or the registered brand name) accordig to their listed policies.

Using these logos (and any derivation but only if they are allowed) and exact brand names (with the registration symbol) is not required in all places (there's a common right of citation as long as there's no attempt to impersonate these brands and let users think that the content is endorsed by the companies owning these brands). Usnig a logo for example is not needed when there's an actual link going to a contributed page that respects the policies of the brand owner of the hosting provider. They just ask to not use these names to create derivations (e.g. creating a conjugated verb or adjective: the brand should remain a noun, treated like other proper names for people names in a way that is natural and does not offense them. Some derivations however have been used and are accepted and even promoted by these sites (e.g. the "Tweetos" for their hosted communities, clearly distinguished from the company accepting them).

So the best way is before using derived names is to see how these brands are advertized by these companies themselves, in formal documents, contracts, business reports, financial reports, if necessary they register additional terms for use in specific contexts, suich as stock symbols, and domain names, but they don't own these terms, just lease them for a limtied period of time which is not warrantied for extended periods of time)...

If translations are made for languages that don't naturally use the same script as the registered brand name, standard transliterations rules (not translations) are usable. In specific countries or juridictions, these derivations may even be legal. If the name is to be used in translatable pages, the original brand name should still be displayed if there's no other clear indicator of the brand (such as a link using a non-masqueraded domain name). Usnig "URL shorteners" that do not link directly to the original websites is not acceptable. Generally these hosting companies provide kits to help create suitable buttons, links, or using documented API entry points, and developers should then follow the documented practices, but should still follow the requirements set by laws for privacy). Mere links are also acceptable in most juridictions.

If users have doubts, they should read the "About" page of these companies, read the user agreements and policies and respect the contracts they accepted when joining to these hosting sites. As well linking to user pages present on other hosted sites is generally not acceptable, and care must be taken so that these personnally identifiable users have their privacy respected. On this wiki or other MediaWiki-based sites, we have a __NOINDEX__ that wiki user pages can add to prevent theur user pages linking to other third party sites to be indexed (wikis use existing standards that search engines have legally advertized that they should respect). However brands are not subject to privacy restrictions that are about physical persons only. But for an isolated use of a brand name needed for a correctly identifiable citation whcih makes no other assertion or association about these brands jsut because of the presence of that single word or expression, there's nothing wrong. You can then translate things like "Modern Art Museum", and add a precision of needed (such as a city name or country name). This is frequently needed for names of national institutions (which are only unique and reserved on their juridiction and subject to local laws and protections or restrictions only there, but not elsewhere; that's why brand names aloen are not sufficient, and all brands have registered logos that should then not be altered even if theese logos are explained or vocalized as a hint).

If you create a document using or citing these brands, and it is valid at the time of publication, but later the company changes its brands, you are not required to change these brands at the same time: on a wiki, all hosted documents have a dated history. Brand owners however ha a right to oppose such citations that would not conform to their current or new policies. All wikis should have a contact form for such legal requests, allowing to negociate what should be the best form of citation (as long as it does not violate a legal but respectful and right of citation, as needed on all news medias and for preserving the freedom of speech).

Logos are not translatable here so they are not an issue (all we have is a possible link to an image following the logo usage policies and showing the necessary copyright statements and legal verbiage needed, on the image description page). If we cannot use these logos for copyright reasons, we can still cite the brand names and domain names as logn as it does not violate other security or user privacy policies or legal requirements).

Is this a verb or a noun, would be great to know!

It's a noun. I've already added this to documentation. Maro21 (talk) 12:32, 2 April 2023 (UTC)

This one needs to change to have a lowercase "R". I thought I'd try to do this myself, but I don't understand TranslateWiki. Do I have permission to change the translation? I get a ready-only textbox.

I think it's already solved? https://translatewiki.net/w/i.php?title=Osm%3ANotes.show.report%2Fen&diff=prev&oldid=10845983&diffmode=source

Hint for translators: You may have noticed a lot of new strings added in March. There was a code reorganization in March, so it looks like there are new translations. However, these are old translations, just under a different path. If you don't want to translate anew, the old translations can be found here (only if they have already been translated in the past. So this is a hint for active languages):

• /copyright page: https://github.com/openstreetmap/openstreetmap-website/commit/68bd99b2bcc896ed2bbac4a88ed591389d9d15aa#diff-e99e1edd6d5248bd77eb7d751b5c09d8ffff4315a3434d78b7180f3c162028ed
• https://github.com/openstreetmap/openstreetmap-website/commit/b078b6b10bdb33121a02a1bd23038c4fef199be5

Maro21 (talk) 11:55, 2 April 2023 (UTC)

What kind of crossing does this message refer to? A place to cross the road (like a pelican crossing) or a place where two roads cross (like an intersection)?

To any node tagged with highway=crossing. https://wiki.openstreetmap.org/wiki/Tag:highway=crossing Maro21 (talk) 11:41, 2 April 2023 (UTC)

the link is incorrect (not a complete URL, just "www.and.com"). But even that domain is no longer owned and is now shown to be soon for sale (on GoDaddy), it may be cybersquatted at any time, if it is not renewed in the short grace time. We need a replacement link ot disable that invalid link. Where can we contact the legitimate owner of the copyright statement on the "AND NL" dataset, to see if they propose a contact point elsewhere? That very short domain name in ".com" will be valued very high!

At least, even if there's no website working on that domain, it should be owned by a trustable party controled by the copyright owner. We must not force OSM data users to visit a malicious website (once it has been cypersquated) because data users they want to act legallyand check their legal rights, where a new cybersquatter could be making false copyright statements on part of the the OSM dataset, or claim invalid costs to be forcibly paid by OSM data users, or taking risks of being contaminated by attacks (even if later that domain would be blocked). But a legal purchase by a legal company could expose new risks to the existing dataset, we must then clearly state who really owns that "AND NL" copyrighted data and where thay can be realiably contacted.

Reported here: https://github.com/openstreetmap/openstreetmap-website/issues/3998 Maro21 (talk) 23:18, 1 April 2023 (UTC)

This string is not being published, although it's correct.

This is a bug of the local message parser that does not handle that syntax for "PLURAL" (not "PLURAL") correctly, it does not accept the "zero=" parameter, and incorectly manages optional values (doesn't accept them if one clause returns an empty string), doesn't accept other clauses needed for other languages (notably in Asia), and just assumes that there can be two clauses, "one=" and the default value in last position, both having non-empty values (at least one space). The bug is reported multiple times in this support page (it is the fault of TWN; not OSM)

All messages in the OSM project using the proposed "PLURAL" exposed in the English source have this problem in all target languages of translations.

But its correction awaits some changes pending since long and needed on OSM (to support other languages that need more than 2 grammatical plural forms and an optional zero, but also without assuming that the default for zero is a plural, and offering a solution when the plural forms depends on sveral distinct values because it a single value is passed implicitly).

For now the best you can do is to submit the syntax that should work, even if it remains "fuzzy", and then contact the OSM support to propose a syntax that it will test; they will then update the translation here themselves to make it disappear, or a local admin will submit your proposal, using their admin tools; for now leave it fuzzy and let admins see if this can work when they test it without the fuzzy tag. It will be validated externally OSM developers and TWN admins have to decide what to do for the supprot of plural forms in their apps or within their export/import tools if they need to convert these messages into a syntax that the OSM website can process correctly. Until some development is made by OSM, everything such issues will have to handled manually by them (just recall them that there are new pending "FUZZY" messages to handle (once again for all messages that were recently modified in the sources and can't be updated correctly due to this longstandanding bug whose resolution is always postponed; this does not block them to update their website in English but makes its localization to other languages problematic as their support by the small core OSM technical team managing their website is still considered "non-urgent", even if it exists since many years, or they are not trained enough to work seriously on l10n issues and have still not granted access to other trained developers to test that essential part of their international websites and core applications.

Thank you for the explanation.

translatewiki simply refuses to accept the zero= clause in the PLURAL, even though that is present in the original.

That's a problem of the validator that does not accept "zero=" clauses if their assigned value is empty (but if this occurs for end of word, e.g. a plural mark, you may still enter "zero= " with a trailing space, and it works. Note that this is not useing the MediaWiki syntax (where "PLURAL:" has a required colon before the numeric value); here the syntax used by such messages in OSM are passnig the numeric value implictly, meaning that if there are different numbers in the same message not taking the same plural mark, it is not possible to correctly translate such message, unless the message is split into a patchwork, a bad practice; the OSM website should use a better i18n library in that case, but it would then require also change the validator rules used in TWN!).

Still there remains the bug that we cannot still assign an empty value to any case branch of the colon-less PLURAL syntax, and with that syntax you cannot add or remove cases (e.g add a "zero=", "one=", "two=", or "few=", "many=" only when needed by target languages, in addition to the final default plural case that cannot be assign an empty value): this is a local TWN bug (due to incorrect simplistic assumptions), and not the fault of OSM's message i18n support code.

Thanks, I'm aware of all that. This is the designated place to report these issues so I'm hoping tw.n staff will eventually notice it.

May be, but I wanted to precise that this is a problem that may have several causes and needing cooperation between what needs to be fixed between TWN and OSM.

You did not provide any link to a sample message and the language where this cause problem, to demonstrate it. However the solution using a space after "one=" may be a workaround in some use cases (note that this space will be part of the extension, it is safe in HTML when used at end of words that are followed by an unconditional space (and not directly by a punctuation; but if this is the case you can move that trailing punctuation inside the "one=" case, and add it also into the last default case).

Such workaround can still be useful even if the problems are fixed later, and they should continue working, while rendering the correct message in the interim. If there are other use cases where there's no clear workaround (without using a "kludge" formulation), it's even more useful to give an example link to the message.

• I think such cases needing more cases will likely occur in Breton, Irish, Slovenian, Slovak, Croatian, Bosnian, Montenegrin, Serbian, Macedonian, Ukrainian, Belarussian, Russian, Hebrew, Arabic, and so on; possibly also in agglutinating languages or languages with complex derivation rules with affixes like Finno-Ugrian languages (Hungarian, Finnish?).
• For many Asian languages that usually don't mark the plural (except by repetition of some words, or by adding some adverb-like or adjective-like word), we also need to be able to remove the "one=" case, even if we keep an empty {{PLURAL}} tag (or a dummy {{PLURAL|word}} that reduces to just that word) somewhere in the message (that will be silently discarded when rendered, or when imported in the target project, but will be there in TWN to mark that this was taken into account, and to avoid generating a warning in the Translate UI and a "!!FUZZY!!" mark in the stored message that would block its export, so that it can still be validated). And for many of these East Asian or South-east Asian languages, the workaround that uses a space cannot be used, notably in the middle of sentences, where there's no space separation between words (that's why this workaround cannot be a general solution for all cases and we need something else to be fixed, here on TWN for the validator, and on the OSM site to implement and use a better i18n function to support the expansion of PLURAL tags themselves)
• The same is true on other websites and application using Gettext, which itself does not support variable placement and expansion of plural markup stored inside translated messages (but only a reduced form with an implicit number, and otherwise needs separate messages to be translated for each contextual plural form needed). A good example of an application not based on MediaWiki is Freecol, which has developed such i18n framework to support plural tags inside messages, and a generic tag that can be used to support many other grammatical forms. Another development is going on for the Multilingual Wikipedia with Wikifunctions, which could take the Freecol as a good example of what may be done. Later, there may be a new solution adopted in CLDR to be documented and supported in various i18n frameworks, describing what a suitable i18n libary should offer. For now, each target platform proposes specific solutions for linguistic text variants and CLDR just describes the few plural forms needed for small fragments of text, but not for complete messages and not for all other linguistic variants (notably the grammatical case and grammatical gender).

CLOSED This issue is closed

String:

• Read more about using our data, and how to credit us, at the <a href="http://osmfoundation.org/Licence">OSMF Licence page</a> and the community <a href="http://wiki.openstreetmap.org/wiki/Legal_FAQ">Legal FAQ</a>.

The original URL and the following text has an error. It's "License" and not "Licence" (page not found on osmfoundation.org). Can someone correct the source english string?

Both work now: https://wiki.osmfoundation.org/wiki/Licence https://wiki.osmfoundation.org/wiki/License Maro21 (talk) 00:38, 15 October 2022 (UTC)

OPEN This issue is open, waiting for action

The Windows Live brand has been long discontinued. You can find a list of what Windows Live services were renamed to here.

I believe the replacement word should be 'Microsoft account'. Please update the icon on the login page and the following strings to reflect this change: https://translatewiki.net/wiki/Osm:User.login.auth_providers.windowslive.title/en and https://translatewiki.net/wiki/Osm:User.login.auth_providers.windowslive.alt/en

Refers to:

• Auth.providers.windowslive
• Sessions.new.auth providers.windowslive.title
• Sessions.new.auth providers.windowslive.alt

Please report it to https://github.com/openstreetmap/openstreetmap-website/issues Maro21 (talk) 00:35, 15 October 2022 (UTC)

CLOSED This issue is closed

Please clarify if this is a about a betting place or a place where books are made (books to read I mean). Thanks.

This is a name of https://wiki.openstreetmap.org/wiki/ES:Tag:shop%3Dbookmaker. The message has documentation already. Maro21 (talk) 00:27, 15 October 2022 (UTC)

Every time I try to publish the correct translation for this string, that is

{{PLURAL|zero=Perunu cummentu|one=%{count} cummentu|%{count} cummentos}}

I get this error message:

Publishing the translation failed: Translation contains syntax errors

Plural forms should be defined as {{PLURAL|one=…|…}}. This translation contains {{PLURAL|zero=…|one=…|…}}.

What can I do? Is there a way to publish it without getting a sintax error? Do I have to ask to an administrator?

The same thing happens with Osm:Issues.show.reports/sc, where the translation should be {{PLURAL|zero=Perunu informe|one=1 informe|%{count} informes}}

Sardinian has already been added to Rails i18n 5 days ago.

That's an issue of this wiki that does not accept the "|zero=" parameter; you may still be able to translate without it, using only singular and plural (if the zero case is already one of them, it will be taken accordingly dor your language), but this means that you still cannot use special non-numeral forms for zero such as "No comment", which will then look like "0 comment" or "0 comments" depending on the language rules.

Is there no way to add "|zero=" to Sardinian too? I've seen that Italian, French, Spanish, Catalan, Portuguese, Venetian, Asturian, Occitan, Galician and many other languages all have it in their translations.

That's because they were first edited "without the zero option", then a requet to local admin (or to the upstream projet maintainer via bug requests) was made to have him adding the missing option (which the current version of the "Translate UI" extension still does not validate correctly.

There's a pending discussion about the problem of adding specific selectors to the PLURAL parser function. In almost all languages zero maps the same grammatically as the singular or plural plural type, but is distringuished only in lexical form or an alternate form (instead of using numeral figures), such as a grammatical or semantic negation like "no", "not", sometimes also agglutinated like "neither" or abbreviated with elision, but sometimes even if the 0 numeral is used this alters the grammar, for example of verbs, or the grammatical case. Those forms for zero are very language specific and contextual, it's hard to hard code in a generic plural form, and for some projects that have limited support of plural rules the number of allowed forms is fixed (including MediaWiki itself, not just GetText), and for now there's no clear support for fallbacks for additional alternatze forms, so they have to be tweaked one by one and tested.

So by default the "zero" plural form remains forbidden as there's still no way to automate how fallback work and how many forms are requried to validate the translation automatically: the "Translate UI" uses a conservative test using a static number of forms and, even if some projects support some additional forms with specific selectors. Note that even CDLR does no specify how missing plural rules are falling back: the only fallback rule supported for now is to fallback to the last plural form given, which is generally the generic plural (but this does not work well for languages where 0 is singular; and there are dificulties for Slavic and Celtic languages, as well as Arabic, or with specific terms that need specific forms, including in English such as "no one" instead of "no person" which are grammatically singular, or "zero persons" which is grammatically plural!). That's in fact still an issue also in CLDR, and there's no solution for now with GetText (so projects using GetText use specific code to handle the translation of zero values, using separate translation units). It's hard to formalize in rules that can pass an automated check and validation.

Ok, thank you very much for the detailed explanation! I've now translated them without the zero option, I will try to find someone that will be able to add it later.

Se tutea o se ustea? En el resto de páginas (relativas a las trazas GPX) se ustea, pero en esta se tutea. Cuál es el estándar?

In fact, I would like to know the guidelines for Spanish translation. There are different ways to speak with the user: informal but familiar (tutear: Tu traza GPX), formal and distant (ustear: Su traza GPX), formal but different across countries (vosear: Vuestra traza GPX).

It's not very clear what "internal" here is meant to signify. I notice a few of the translations just keep "internal"; is "internal" meant to mean "from the map data" (which doesn't quite make sense), or what?

@আফতাবুজ্জামান: দাদা ইনি কী বলছেন দয়া করে একটু দেখুন!

This message cannot be translated. It keeps complaining about a syntax error due to the presence of the "zero" clause even though that is in the original message.

It might be because they are in the "wrong" order.

No, the order is completely correct (and chaing it would have no effect).

This is a known current bug of TWN, which no loger accepts the "zero" plural option for any language, because it restricts these options to only the numbered options for (default) plural rules of the language. It was valids in the past, but a change in TWN code caused this new caveat under a false assumption that extra values, than just option 1 for singular, and the last (implicitly numbered) option for default plural would be invalid.

But many messages in Mediawiki define specific values (such as "zero=", "one=", "99+=", or other numeric values like "10=", "100="); such cases occur as well in English, but are more frequent in languages that need additional context-specific rules than just the basic default rules).

Even languages that normally don't mark the grammatical plural have specific words or sentence forms in some cases (e.g. expressing zero by using a negated form or changing to another adjective or adding some extra particles). If we don't use these options, the only redering using digits only looks much less familiar and less friendly.

IMHO it's not to TWN to decide the maximum of forms that can be set with plurals (notably not for MediaWiki's {{PLURAL: value | alternate forms... | default form }}, but as well for plural rules used in Python, Java, Ruby or other languages, and i18n libraries such as ICU using CLDR data: if we specify "too many", these extra forms may be left unused by the target application but won't break the message: it must just provide at least the last default form; other forms will be used conditionally but using variable rules.

So TWN may just display a warning, allowing to reconfirm when saving again without other changes (the warning may just say that extra forms may be useless, and should as well send a warning if there are fewer forms than expected (notably in Slavic and Celtic languages or in Arabic, that have more than 2 forms)

N'hallan ket treiñ ar frazenn-mañ. Klasket 'm eus treiñ anezhi met, n'eus forzh penaos, ne laosker ket ac'hanon da dreiñ anezhi ha n'ouzon ket perak?? Trechalet on.

What does mean "Locality"? Can you give an explanatory explanation? --Hedda (talk) 16:14, 17 June 2021 (UTC)

Locality is a tag used to name a place which does not have other distinct features than the name itself, see the OSM wiki for tag=locality.