Proposal talk:Name:Zsye

Note the wiki does not support emojis. You can't use them!

It will drop all your text which is behind the emoji!

but you can add them with 'x3 Html encoding for character 'x3

You can also use #invoke:char.

Unknown values

What are the exact values used for the new tag? For example: I personally don't known how to type the symbol for the statue of liberty in JOSM or iD. --Hauke-stieler (talk) 21:59, 6 January 2020 (UTC)

The emojis are all part of the unicode characters

This really can't be easily done on a PC without special programms.

But one can just copy past the character into Josm or iD.

--Ferdinand0101 (talk) 22:12, 6 January 2020 (UTC)

I don't know it it's a good idea to copy and paste some characters from websites into JOSM or iD. If anything at all, I would use the exact unicodes as values (for example: the US flag would be "U+1F1FAU+1F1F8" I guess), which need to be documented in the wiki so all people use the same (there are sometimes equal looking emojis like the "U+1F1FAU+1F1F2" one, which looks like the US flag but it is the US flag for outlying islands).

--Hauke-stieler (talk) 22:23, 6 January 2020 (UTC)

If you copy the emojis from the unicode website you can make sure they are the correct ones and with your examples of the US outlying islands on my windows pc where the flags don't render one can clearly see that

Perfect example for my suggestion with the actual unicode format of "U+..." because I'm on a Linux system and the two emojis you just postet look absolutely exactly the same. With the textural representation (U+...) one can clearly see that they differ, no matter on what system.

--Hauke-stieler (talk) 22:32, 6 January 2020 (UTC)

I guess doing it that way would make it easier to distinguish the emoji.

but it would also get rid of the searchability and human readable representation.

I would consider such things to be in the applications responsibility. An app (website, search engine oder whatever) should make sure they find the emoji and show it in a correct way. --Hauke-stieler (talk) 23:15, 6 January 2020 (UTC)

That would make sense.(I'll update the tagging example) somehow broke the table don't have time to fix now maybe tomorrow

--Ferdinand0101 (talk) 23:50, 6 January 2020 (UTC)

Updated the draft

--Ferdinand0101 (talk) 04:08, 7 January 2020 (UTC)

Updated it again cause emojis break this wiki

--Ferdinand0101 (talk) 04:27, 7 January 2020 (UTC)

Are you now proposing that the tag should not contain the actual Unicode characters but their codepoints written out as U+XXXXX? Because that would be a mistake. The emoji work fine in OSM, as we've seen in your reverted edit. They also work out of the box in search (provided Nominatim doesn't ignore the new name:Zsye tag, but that should be a minor fix). It works fine on Linux too in the browser; it's just that the wiki-software here can't handle Unicode characters outside of the BMP (which emoji are).

Hauke: it is the application's and the OS's responsibility to render any valid Unicode characters properly. OSM is not limited to characters on the BMP. Tools such as JOSM will eventually use newer versions of Java that support rendering these glyphs, but it is already possible to copy/paste them from more modern applications (e.g., on Linux: gucharmap). In Ubuntu 16.04 I can use and compose these emoji, but only see them rendered in the browser, on Ubuntu 18.04 they are already rendered properly in the OS, and I can see them rendered in most applications.

It would be akin to arguing that Arabic or Japanese names should always be transliterated to Latin text, because users might not have fonts installed that can show them. JeroenHoek (talk) 18:30, 8 January 2020 (UTC)

That's not excatly true because some emojis are literally identical in terms of viewing which was the main concern.

and about the point with the supported fonts the tags which I recently added are only supported on verry few platforms (originally only whatsapp now a few more) because they aren't a part of the "main" unicode standard

Do you mean the sequences for the flags of England, Scotland, and Wales? These are part of the Unicode standard. The other flags all work in most modern operating systems and browsers. JeroenHoek (talk) 20:01, 8 January 2020 (UTC)

--Ferdinand0101 (talk) 18:52, 8 January 2020 (UTC)

but I have also considerd something like name:Zsye and name:Zsye:codepoints which could solve that

--Ferdinand0101 (talk) 19:20, 8 January 2020 (UTC)

That would lead to duplication of data, which is undesirable as well. JeroenHoek (talk) 20:01, 8 January 2020 (UTC)

While might be undesireable It would only be ~1kilo byte more for all which I'd say is worth it for compatability and it's not a big deal for a dataset with a size of over 1tb

--Ferdinand0101 (talk) 20:54, 8 January 2020 (UTC)

No indeed, size is not the problem. But you do create two tags that should always be in sync. Anyone editing them, would have to edit both at the same time. That makes the addition of the codepoint-tag redundant. Data consumers can all read valid Unicode characters, so they don't need it. Mappers interested in this tag will expect to be able to copy/paste a flag or other emoji, so they don't either. For the sake of the proposal I would stick to you original intent. JeroenHoek (talk) 07:20, 9 January 2020 (UTC)

okay I have changed it back again for the proposal --Ferdinand0101 (talk) 08:25, 9 January 2020 (UTC)

Key name

It is probably better to propose just one key-name in the proposal, and leave any doubts about these here on the talk-page. It makes the proposal easier to understand. I would suggest name:Zsye. JeroenHoek (talk) 08:01, 8 January 2020 (UTC)

name:Zsye has at least already been used for China already and it is also my preferred version but I wanted (and still want) feedback on that.

--Ferdinand0101 (talk) 10:01, 8 January 2020 (UTC)

It's probably best to submit your preferred version in the proposal, and link to this talk page for alternatives that may be considered. JeroenHoek (talk) 10:24, 8 January 2020 (UTC)

That's why this is still the draft because I want to figure things like that out

--Ferdinand0101 (talk) 18:54, 8 January 2020 (UTC)

Why the capital letter in 'Zsye'? Most tags are in lower case, and, more importantly, most language codes are in lower case - with the exception of scripts ("name:sr-Latn"). --Mueschel (talk) 18:50, 29 January 2020 (UTC)

Because it is a script-code, exactly like Latn. The capital Z is part of the code. JeroenHoek (talk) 18:54, 29 January 2020 (UTC)

Makes sense. Thanks!

Further expand on types of emoji sequences

There are a number of possible emoji sequences that can be sensibly applied to OSM entities. I would suggest listing these in order of importance in the proposal, with links to relevant documentation and examples:

• Regional Indicator Symbols: these are based on the ISO 3166-1 alpha-2 codes, and tend to render as flags.
• Tags (Unicode): these are an additional, alternative way of indicating flags, currently used for England, Scotland, and Wales.
• Emoji pictograms: these include emoji that are graphical representations of (specific) OSM elements; e.g., U+1F5FC (Tokyo Tower), U+1F5FB (Mount Fuji), and U+1F5FD (Statue of Liberty).

Most emoji-tags will be the first group, representing country flags based on ISO 3166-1 alpha-2. In the future you may expect the Tags group to expand with flags for states, prefectures, districts, and provinces; at the moment only three flags are represented there.

The final group of pictograms is limited, and is not likely to grow very much. These are present in Unicode for compatibility reasons: they were introduced by Japanese telecom in the late nineties and noughties, and were (and are) used extensively on Japanese mobile phones. This set may be expanded with some applicable icons, but not much.

What do you mean with Emoji pictograms ?

Tagging things that are "unique" and have an emoji (like statue of liberty) or would you like to tag all highway as emoji=U+1F6E3 U+FE0F

About the tags: the ones that are recommended for general use should be added I'd say

--Ferdinand0101 (talk) 09:58, 8 January 2020 (UTC)

The wiki broke on the emoji in my comment and part of the comment was dropped as a result. Amended above. JeroenHoek (talk) 10:21, 8 January 2020 (UTC)

also I'd like to say except the tags the unicode pictogramms and regional indicator flags are already part of the draft

--Ferdinand0101 (talk) 18:14, 8 January 2020 (UTC)

I've added the tags to the tagging examples

--Ferdinand0101 (talk) 18:26, 8 January 2020 (UTC)

To explain to the community who will vote on your proposal what the nature of this tag is, you might want to explicitly document the above in your proposal. That is: name the three groups, link to Wikipedia and the Unicode website (like I did in the list above), and summarize how many OSM entities can currently get a name:Zsye-tag (how many flags via Regional Indicator Symbols, how many via Tags, how many as pictogram/icon). You have to convince people this idea is worth it, so be clear about what will happen, and what might happen (like state flags in future Unicode releases). You are welcome to take my text and adapt it to your needs. JeroenHoek (talk) 07:20, 9 January 2020 (UTC)

Thank you I have added a slightly adapted version to the draft --Ferdinand0101 (talk) 08:24, 9 January 2020 (UTC)

I'll move the main site soon

If y'all want to say anything pls do so now before I move it and start the RFC phase

Why?

https://lists.openstreetmap.org/pipermail/tagging/2020-January/050031.html remains not answered. Why someone would need to search by emoji? Mateusz Konieczny (talk) 20:58, 27 January 2020 (UTC)

Why indeed? Sounds like the most useless tagging yet. Let's also be realistic here, at best you get a graphical representation of a flag so why is it a name tag? The flag of the USA is not the name of the country. If you want to indicate what the flag of something is don't we already have flag:wikidata for that? Or if you want a picture of the Kaaba, then click on the Wikipedia link. Adavidson (talk) 05:26, 28 January 2020 (UTC)

I would say : why not ? Maybe search isn't the best use case, but could be interesting to display emojis in geocoding search results for example. We should not forbid adding information that could be interesting at some point, it's more interesting to agree on best tagging for it. Flag is not generic enough, as you have emojis for famous POIs like Tokyo Tower or Statue of Liberty. Maybe symbol:Zsye=* ? --PanierAvide (talk) 07:16, 28 January 2020 (UTC)

I think there is a valid case to be made for search. These emoji do occur in the wild (e.g., in chat conversations and social media), and it isn't too far-fetched to think of simply copy and pasting a flag you don't recognize in a digital map and get the corresponding geographic entity. That's actually kind of neat.

As for the tag; the proposal does indeed go beyond flags, all though in practice the majority of them will be. There is a strong case to be made that emoji can be considered a form of (pseudo-)language on their own, and using the name-namespace means that data-consumers (e.g., Nominatim) can treat them as any other name-tag, which is appropriate. The fact that it has a formally assigned ISO-15924 script-code (Zsye) lends some wait to that argument too. In any case, I don't find it too far-fetched to think of a flag or pictogram of an entity as its 'name' in Zsye. JeroenHoek (talk) 07:30, 28 January 2020 (UTC)

For flags it is saving country code in less editable and less readable form. And country codes are tagged already. Mateusz Konieczny (talk) 07:57, 28 January 2020 (UTC)

The flags represented by Regional Indicator Symbols are just one of the three categories of applicable emoji represented by this proposal. The future of the Tag set in particular is interesting, as it could very well end up containing regional flags/symbols for provinces, states, prefectures, województwa, et cetera. (Currently this set is limited to the three country flags of the British union.) These cannot be (automatically) derived from the existing codes. As for readability, that is a valid concern, but countries on OSM are generally watched closely by local mappers. Any misstagging in name:Zsye will likely be spotted as fast as mistakes in ISO3166-1:alpha2, especially since the emoji flags are rendered properly in modern browsers (it worked fine in Firefox on Linux after Ferdinand pushed his ill-fated and short-lived changeset before starting this proposal).

As for redundancy: we tag both ISO3166-1:alpha2 and ISO3166-1:alpha3 too, and ISO3166-1.

Aesthetically speaking, the flags actually looked kind of cool too. JeroenHoek (talk) 08:24, 28 January 2020 (UTC)

To answer your question, this use-case is just one that springs to mind: being able to copy a flag from someone's name or post on Twitter or any other medium — perhaps something about it piqued your interest — and instantly get the location and name(s) of the locality it represents on a map when you use it as a search query. JeroenHoek (talk) 08:29, 28 January 2020 (UTC)

I understand that searching for emojis is useful, but can't this be implemented in the search application, rather than being stored as a hard-to-maintain tag in the database? --Jeisenbe (talk) 06:49, 13 February 2020 (UTC)

The codes might be derived computationally from the ISO3166-1:alpha2 tags, but this only goes for one of the three emoji categories this proposal mentions. There is also no guarantee that every valid ISO3166-1:alpha code matches a valid Zsye emoji. In the brief period that the name:Zsye tag was added without going through the proposal process the flags looked rather nice too in the data tab on openstreetmap.org. I don't think that these tags are hard to maintain: on the contrary, because of their limited number and high visibility (people will notice when the flag for their country doesn't match) these are likely to be easier to maintain than, e.g., the ISO3166-1-tags. JeroenHoek (talk) 08:36, 13 February 2020 (UTC)

Language code

I think Zsye is a suboptimal subkey for this purpose. Data consumers and editors such as iD currently assume that localized name subkeys follow a certain pattern, to distinguish them from non-language-related subkeys like name:pronunciation=*, name:etymology=*, or whatever arbitrary detail a mapper might want to provide about a name=*. While a bare ISO 15924 script code is a valid BCP 47 language tag, it would be unfortunate if data consumers had to special-case this one key, special as it may be.

Until now, all the commonplace name:* subkeys for transliteration have begun with an ISO 639 language code, for example name:zh_pinyin=* and name:ja-Latn=*. This is the first time we've considered a transliteration system that is intended to be associated with all languages. If I'm not mistaken, the ISO 639-2 code mul is intended for translingual content, so I'd suggest using name:mul-Zsye=* rather than name:Zsye=*.

 – Minh Nguyễn ^💬 20:13, 21 February 2020 (UTC)

According to 2.1 in https://tools.ietf.org/html/bcp47 a bare ISO 15924 code is not a valid BCP 47 tag. So en is valid, en-Zsye (English written in emojis) is valid, and en-Zsye-NZ (New Zealand English written in emojis) is valid. Zsye is not. Adavidson (talk) 09:14, 9 March 2020 (UTC)

Wikidata

By the way, regardless of this proposal, it is possible for a data consumer to determine the emoji representation using Wikidata. Using one of the examples in the proposal, the Kaaba is tagged wikidata=Q29466, and that Wikidata item has the Unicode character (P487) property set to 🕋. Some renderers and search engines already cross-reference Wikidata like this to backfill translated or transliterated names.

A search engine could extend this approach to also support searching for amenities using emoji or dingbats: amenity=cafe's data item has the Wikidata concept (P12) property set to Q30022, which has the typically sells (P7163) property set to coffee (Q8486), which has the Unicode character property set to ☕. Users wouldn't have to think about which kinds of emoji a search engine supports, and meanwhile we don't have to tag amenity:Zsye=* everywhere. 😉

 – Minh Nguyễn ^💬 21:12, 21 February 2020 (UTC)

This Wikidata Query Service query and this Sophox query both demonstrate the feasibility of cross-referencing Wikidata to map emoji to places (both countries and one-off landmarks). The queries are speedy enough that they could even be run on the fly, though it'd be better to cache and bundle the results in an application, since the set of emoji change at most once annually. – Minh Nguyễn ^💬 19:11, 6 July 2020 (UTC)