Utilização de etiqueta name:pt-BR

[matheusgomesms (Matheus Gomes)]

Olá, comunidade BR!

Esta semana, ao editar uns locais, percebi que tem nomes em PT e PT-BR diferentes, como por exemplo:

Romênia/Roménia
Macedônia/Macedónia do Norte
Irã/Irão
Vietnã/Vietname
Polônia/Polónia
Groelândia/Gronelândia

…e por aí vai.

Justificativa: Isso impacta diretamente utilizadores de dados localizados, como renders ou busca. Ou seja, um brasileiro utilizando um serviço OSM localizado (como vector tiles ou app de mapas) verá Vietname, ao invés de Vietnã.

Sei que as variantes PT foram unificadas na wiki em 2014, mas nos dados OSM em si, como podemos fazer?

No OSM, se usa os códigos ISO 639-2, onde consta somente pt. Contudo, temos vários casos de variantes, como o Chinês que tem zh-Hans e zh-Hant.

Falei com a comunidade PT, e de acordo com algumas discussões na wiki, tais como esta e esta, o que poderia ser feito no Brasil era utilizar a etiqueta name:pt-BR (desse jeito, com o código do país em maiúsculas, separadas por hífen) para estes casos.

Sendo assim (e vamos discutir, claro!), proponho:

1 - não alterar o entendimento de que a etiqueta name:pt é a única que representa o Português.
2 - não alterar o entendimento do uso da etiqueta name=* (ou seja, ela representa o nome do objeto no idioma local)
3 - utilizar name:pt-BR somente nos casos em que a variante brasileira for diferente da portuguesa, e utilizar name:pt como já é usado, como padrão. Em outras palavras, name:pt=Irão; name:pt-BR=Irã.

Ou seja, pouca coisa muda, a única coisa que de fato é alterada é a introdução e padronização da etiqueta name:pt-BR. Hoje temos duas etiquetas, name:pt-br e name:pt-BR, com menos de 30 casos combinados.

O que vocês pensam?

[matheusgomesms (Matheus Gomes)]

E como sugerido pelo @AntMadeira, esses seriam os respectivos códigos para todos os países que usam o português de alguma maneira:

português (pt)
português (Angola) (pt-AO)
português (Brasil) (pt-BR)
português (Suíça) (pt-CH)
português (Cabo Verde) (pt-CV)
português (Guiné Equatorial) (pt-GQ)
português (Guiné-Bissau) (pt-GW)
português (Luxemburgo) (pt-LU)
português (Macau, RAE da China) (pt-MO)
português (Moçambique) (pt-MZ)
português (Portugal) (pt-PT)
português (São Tomé e Príncipe) (pt-ST)
português (Timor-Leste) (pt-TL)
português (Mirandês) (pt-mwl)

Edit: Mirandês já tem seu código em uso no OSM: mwl.

[fititnt (Rocha)]

@matheusgomesms

1 - não alterar o entendimento de que a etiqueta name:pt é a única que representa o Português.
2 - não alterar o entendimento do uso da etiqueta name=* (ou seja, ela representa o nome do objeto no idioma local)

Eu também acredito que, similar ao name= ser idioma local, o name:pt= também deveria ser idioma local.

Vamos dizer que as receites discussões como esta aqui https://github.com/openstreetmap/openstreetmap-website/issues/3670 que assume que pt poderia ser compreendido como Português do Brasil em caso de multiplas variantes, eu acredito que para nomes locais, além do name, o name:pt= tenha liberdade para seguir a grafia mais comum na região. Na prática, isso poderia implicar que name:pt= em Angola e Timor-Leste (quando já não for idênticas) tender a seguir o português europeu.

[fititnt (Rocha)]

@matheusgomesms

Ou seja, pouca coisa muda, a única coisa que de fato é alterada é a introdução e padronização da etiqueta name:pt-BR. Hoje temos duas etiquetas, name:pt-br e name:pt-BR, com menos de 30 casos combinados.

== Se for necessário específicar região, então o ideal é o código do país ser em caixa alta ===

Embora parseadores deveriam tolerar caixa baixa, tanto para scripts (Latin em pt-Latin-BR, como país (BR em pt-Latin-BR) existe uma sugestão que melhora legibilidade. Então, a não ser que haja um motivo forte contrário (em geral quando meio de comunicação não consegue diferenciar caixa baixa e caixa alta, ou quando é necessário usar menos bytes) pelo menos para o que estiver na OpenStreetMap deveria seguir boas práticas.

=== BCP 47 / RFC 5646 ===

Para quem tem interesse, é a BCP 47 / RFC 5646 que formaliza isso.

Na Wikipedia

IETF language tag

Na explicação formal

RFC 5646: Tags for Identifying Languages

---

PS.: eu conheço parte dessa questão toda técnica porque já tive que criar parseadores da language tag. E, só para avisar, a maioria dos programas não respeita estritamente a BCP 47 / RFC 5646, que por exemplo até explica como, por tentativa e erro, petar o código mais apropriado sem precisar colocar copia de todos eles. Se necessário, pelo menos para softwares mais usados, eu me disporia a ajudar eles a entender as sintaxes

[waldyrious (Waldir Pimenta)]

Acho que convinha deixar claro que name:pt não é suposto representar o nome usado em Portugal, mas sim o nome em português como é escrito na maior parte dos países/comunidades lusófonos.

Por exemplo, se um nome só é usado em Portugal e outro só é usado no Brasil, então pela lógica devia ser name=<nome local>, name:pt-BR=<nome no Brasil>, e name:pt-PT=<nome em Portugal> (name:pt-PT e não name:pt).

Dito isso, na prática o que acontece mais frequentemente é o nome usado em Portugal também ser o usado nos outros países lusófonos, daí a meu ver se justificar que a documentação diga algo no estilo de name:pt=<nome na maioria dos países lusófonos> e name:pt-BR=<nome no Brasil> (e, se acharmos necessário, name:pt-PT=<nome em Portugal>).

Espero não ter sido muito confuso!

[fititnt (Rocha)]

@waldyrious

Acho que convinha deixar claro que name:pt não é suposto representar o nome usado em Portugal, mas sim o nome em português como é escrito na maior parte dos países/comunidades lusófonos.

concordo!

@matheusgomesms

3 - utilizar name:pt-BR somente nos casos em que a variante brasileira for diferente da portuguesa, e utilizar name:pt como já é usado, como padrão. Em outras palavras, name:pt=Irão; name:pt-BR=Irã.

No Vocabulário Ortográfico Comum da Língua Portuguesa, pelo Instituto Internacional da Língua Portuguesa (do qual sim, Brasil também é parte) essa é a entrada para o país Irão/Irã

https://voc.cplp.org/index.php?action=toponyms&act=details&id=TER.142.034.IR

Não existe uma diferenciação explícita entre país onde é ou não usado o termo. Ambos são tratados como variantes do mesmo conceito. Eu até entendo, por exemplo, que para fins comerciais (como filmes de Netflix) em especial por causa da sonoridade das palavras possa ser mais relevante, os professores de português ao redor do mundo tendem a querer compatibilizar os termos. Por exemplo, vão estar mais preocupados em acertar o gênero do termo e (ao escrever) usar (o) Irão e não irão, pois o primeiro é nome próprio (mais especificamente, toponímico), e o segundo é também um verbo.

Eu acho essa discussão relevante, mas para toponímicos, vai ter menos impacto do que por exemplo documentação na Wiki para se referir a conceitos, pois toponímicos tendem a ser próximos, enquanto termos para se referir a algo podem ter sinônimos (e alguns deles serem completamente diferentes, incompreensíveis)

[fititnt (Rocha)]

Sobre esse exemplo:

@matheusgomesms

Macedônia/Macedónia do Norte

Macedônia/Macedónia parace ser uma região, vide https://pt.wikipedia.org/wiki/Macedônia_(região)

Macedônia do Norte/Macedónia do Norte creio que é o toponímico, vide https://pt.wikipedia.org/wiki/Macedónia_do_Norte.

Um nome ser popular no português como falado no Brasil para um toponímico estrangeiro não quer dizer que tal nome popular é a grafia correta daquele termo mesmo na opinião de professores de português no Brasil.

Meu argumento é que existe diferença, mas ela é menos significativa. E pelo menos para nomes de lugares relevantes, esse cuidado é relevante. Pense OpenStreetMap como uma enciclopédia.

[AntMadeira]

Um pouco além da discussão dos códigos, seria importante perceber que impacto (se é que haveria algum) esta medida iria ter no OSM, porque não basta criar uma espécie de padronização dos códigos de linguagem, é preciso saber como os renderizadores e motores de busca, como o Nominatim, funcionam agora e/ou passariam a funcionar no futuro.
Ou seja, será que já existe algo implementado internamente por esses sistemas? Se sim, como? Se não, como levá-los a adotar estas propostas?

[matheusgomesms (Matheus Gomes)]

Pessoal, desculpa sumir. Estava bem atarefado e não tive tempo ainda de voltar a essa proposta.

@AntMadeira tem razão, temos de conversar com o pessoal dos softwares para ver o suporte disso.

Tenho plano de voltar a isso em novembro, mas a princípio a etiqueta “correta” para PT-BR é name:pt-BR, de acordo com a IETF, que segundo um usuário daqui é a codificação usada no OSM (também mencionada pelo @fititnt).

[Minh_Nguyen (Minh Nguyễn)]

(Sorry for using English, and for the disorganized thoughts.)

@matheusgomesms

Tenho plano de voltar a isso em novembro, mas a princípio a etiqueta “correta” para PT-BR é name:pt-BR, de acordo com a IETF, que segundo um usuário daqui é a codificação usada no OSM (também mencionada pelo @fititnt).

The IETF’s BCP 47 standard is documented in the “Names” and “Multilingual names” articles. This standard specifies that pt-BR is the IETF language tag for Brazilian Portuguese. The standard is technically case-insensitive, but the well-established industry convention is to capitalize the region code and the first letter of the script code. We used to completely lowercase name:* subkeys, but in 2018, there was a mass migration to mixed case, thus name:zh-Hant instead of name:zh-hant.

According to the standard, pt means Portuguese in an unspecified region. A data consumer is typically aware of both the user’s preferred language and region and will fall back to the unqualified language code if necessary, typically using either the truncation fallback algorithm or the CLDR language matching algorithm. If a feature is tagged with name:pt=* and name:pt-BR=* but not name:pt-PT=*, a user who prefers pt-PT will see the name:pt=* value.

However, if the feature is tagged with name:pt-BR=* and name:pt-PT=* but not name:pt=*, a user who prefers pt-TL may see name:pt-BR=*, name:pt-PT=*, or name=*, depending on the application, browser, or operating system. A data consumer that implements the CLDR language matching algorithm would consider it a tie and probably choose name:pt-BR just because it comes earlier alphabetically. But if it uses the less sophisticated truncation fallback algorithm, the user will see name=* instead.

Unfortunately, some data consumers like OpenMapTiles and Mapbox Streets recognize only name:pt=* and ignore name:pt-BR=* and pt-PT=*. Planetiler-based tilesets have a little more flexibility; I’ve requested support for name:pt-BR=* and name:pt-PT=* for the vector tile server that powers OSM Americana and other community projects.

To avoid inconsistencies, we should try to set all three keys – name:pt-BR=*, name:pt-PT=*, and name:pt=* – whenever the dialects differ, even if some of them have identical values. name:pt=* could be the more locally relevant spelling, the more internationally popular spelling, or a semicolon-delimited list of the two spellings (see the precedent in Chinese). The specific fallback value doesn’t matter very much as long as we fill out as many name:pt-*=* tags as we can.

Miscellaneous technical considerations

For user-facing text, most OSM-related software applications assume that pt is specific to Portugal. Some operating system platforms like iOS expect applications to provide specific Brazilian and Portuguese localizations; for Angolan and Timorese users, the operating system would choose one of them automatically.

Software	pt	pt-BR	pt-PT
OpenStreetMap Website Nominatim		—
Every Door			—
Go Map!!			—
iD iD Tagging Schema Editor Layer Index OSM Community Index			—
JOSM			—
MapLibre Native	—
Mapbox Maps SDK	—
Organic Maps			—
OsmAnd			—
Potlatch	—
StreetComplete			—
taginfo			—
Vespucci			—
Waymarked Trails			—

A few years ago, the iD project discussed using en to represent a compromise “international English”, to avoid confusion among translators into other languages, but this idea went nowhere because it would have created many interoperability problems.

Most software applications don’t have a practical reason to present a mix of Portuguese dialects to the user at the same time, except as a fallback. On the other hand, a mixed-language map is also atypical but common in the OSM ecosystem. We’re using name=* for the name in an unspecified (implicitly local) language, whereas the most specific ISO 639 language code would probably be either mul or und. BCP 47 allows either an ISO 3166-1 country code or a UN M.49 region code in the second position. The UN M.49 code for “unknown” is 0000, but so far no one has ever used name:*-0000, and it could potentially cause confusion with the date namespace that some mappers prefer.

[matheusgomesms (Matheus Gomes)]

Bom, o @Minh_Nguyen já resumiu bem o estado atual do Português no ecossistema OSM. Pelo que entendi, os principais softwares já aceitam bem as 3 etiquetas (pt, pt-BR e pt-PT), resolvendo esse problema de comunicar os desenvolvedores (excetuando o próprio site OSM, onde isso já foi discutido há tempos e está em vias de ser resolvido).

Sendo assim, restaria que nós decidíssemos de fato como essas etiquetas (e as outras variantes, como pt-AO, pt-MZ…) seriam usadas.

Como dito aqui por todos, me parece que o que faz mais sentido é:

name:pt=nome na maioria dos países lusófonos (que no geral é a variante europeia)
name:pt-BR=nome específico no Brasil
name:pt-PT=nome específico em Portugal
name:pt-XX=nome específico no país XX

As variantes name:pt-XX só seriam usadas caso fossem diferentes do name:pt (redundância aqui talvez não seja desejado?). Então vamos usar alguns exemplos (alguns absurdos para fins de discussão somente, que não representam o modo correto de mapeamento):

1 - País
name:pt=Irão
name:pt-BR=Irã
Justificativa: na maioria dos países lusófonos se utiliza a versão Irão, somente o Brasil (?) utiliza a grafia Irã.

2 - POI em Portugal
name=Relvado do Alvalade
name:pt-BR=Gramado do Alvalade
Justificativa: como o POI está em Portugal, o nome principal vai para a etiqueta name, e os demais idiomas vão para suas respectivas etiquetas.

3 - POI no Brasil
name=Gramado do Maracanã
name:pt=Relvado do Maracanã
Justificativa: idem. Contudo, como todos os outros países lusófonos (ou a maioria?) utiliza a palavra Relvado, não faz sentido adicionar todas as variantes, sendo que name:pt já serviria para representar o falado em Portugal, Angola, Moçambique, Cabo Verde etc.

4 - POI em Angola (caso mais complicado)
name=Paragem de Machimbombo
name:pt=Paragem de Autocarro
name:pt-BR=Parada de Ônibus
name:pt-MZ=Paragem de Machimbombo
Justificativa: mesma coisa. Novamente, se utiliza name=* como representado no país local. Neste caso, como Machimbombo é utilizado tanto em Angola quanto em Moçambique (mas o POI está em Angola), mas nos outros países lusófonos (exceto o Brasil) se utiliza Autocarro, opta-se por usar name:pt para representar a maioria dos países, adicionando as variantes MZ e BR para que estes sejam utilizados.

Este último caso talvez seja passível de maior discussão, mas pelo que entendi, o software usaria a seguinte ordem de escolha de nome para um usuário de Moçambique:

name:pt-MZ → name:pt → name

Ou seja, se não há a etiqueta name:pt-MZ, o primeiro fallback seria name:pt, que neste caso 4 estaria “incorreto”, daí a duplicação da etiqueta name para name:pt-MZ.

Já para o usuário de Angola, essa verificação é (ou deveria ser) diferente, visto que o POI está naquele país, e espera-se que a etiqueta name tenha maior prioridade sobre todas as outras.

Faz sentido tudo isso? Que vocês acham?

[Minh_Nguyen (Minh Nguyễn)]

@matheusgomesms

3 - POI no Brasil
name=Gramado do Maracanã
name:pt=Relvado do Maracanã
Justificativa: idem. Contudo, como todos os outros países lusófonos (ou a maioria?) utiliza a palavra Relvado, não faz sentido adicionar todas as variantes, sendo que name:pt já serviria para representar o falado em Portugal, Angola, Moçambique, Cabo Verde etc.

Some data consumers expect that, if any name:*=* tags is present, one of the name:*=* tags matches the value of name=* in order to know which language name=* is in. In fact, one of the osm-carto developers has experimented with hiding the label if the name=* isn’t duplicated in one of the name:*=* tags, although in this case, it would’ve been able to infer that the name=* is in Portuguese, thanks to default_language=* on Brazil’s boundary relation.

[matheusgomesms (Matheus Gomes)]

@Minh_Nguyen

Some data consumers expect that, if any name:*=* tags is present, one of the name:*=* tags matches the value of name=* in order to know which language name=* is in. In fact, one of the osm-carto developers has experimented with hiding the label if the name=* isn’t duplicated in one of the name:*=* tags, although in this case, it would’ve been able to infer that the name=* is in Portuguese, thanks to default_language=* on Brazil’s boundary relation.

So what’s the best approach here? I have the impression that it is not desirable to have duplicate information (for example Louvre Museum doesn’t have name:fr tag), but I have also seen many places like that (in Egypt for example, I’ve seen many important POIs with both name and name:ar tags, with same values).

Not sure if this also deals with countries with many official languages. Brazil, Portugal and São Tomé e Príncipe would not be a problem, but many other Portuguese speaking countries have: many languages (eg.: Angola), Portuguese is not the main one even with official status (Guiné-Bissau, for example), or even Macau (less than 5% of people speak PT there, an official language).

[Minh_Nguyen (Minh Nguyễn)]

@Minh_Nguyen

In fact, one of the osm-carto developers has experimented with hiding the label if the name=* isn’t duplicated in one of the name:*=* tags, although in this case, it would’ve been able to infer that the name=* is in Portuguese, thanks to default_language=* on Brazil’s boundary relation.

Oops, I meant to link to this more recent blog post by the same author.

@matheusgomesms

So what’s the best approach here? I have the impression that it is not desirable to have duplicate information (for example Louvre Museum doesn’t have name:fr tag), but I have also seen many places like that (in Egypt for example, I’ve seen many important POIs with both name and name:ar tags, with same values).

From a data consumer standpoint, I can understand why the wiki has long recommended this measure of redundancy in order to indicate name’s language. But the guideline clearly isn’t followed universally. I think that’s mostly because nothing seems broken to mappers when they omit it.

Some prominent data consumers either use name verbatim (openstreetmap-carto) or implement the truncation fallback algorithm (openstreetmap-website, Nominatim). Neither of these approaches requires knowing that name in Portuguese. The most severe impact you’d normally see from a missing name:pt is that OpenMapTiles and Mapbox Streets fall back to a Wikidata label, ignoring name.

@matheusgomesms

Not sure if this also deals with countries with many official languages. Brazil, Portugal and São Tomé e Príncipe would not be a problem, but many other Portuguese speaking countries have: many languages (eg.: Angola), Portuguese is not the main one even with official status (Guiné-Bissau, for example), or even Macau (less than 5% of people speak PT there, an official language).

When there are multiple official languages besides Portuguese, or when the feature is primarily named in Portuguese but that isn’t the “obvious” language for the area, it’s even more important to tag name:pt even if it’s redundant to name. Otherwise data consumers have to guess, and they’ll probably guess wrong.