[WIP] Remove flags in locale selector

[erciccione]

This reverts #242. See #242 comment

Ping @m52go @wiz

Flags shouldn't be used to rappresent languages, please take a look at http://www.flagsarenotlanguages.com.

[m52go]

As noted in 92593c8, 242 does the following:

• Use full language name instead of two letter language code
• Use flag emoji instead of two letter country code
• Fix sort order of locale selector pull-down

Your point about flags is valid, which means that the issue is with the second point only, so I don't think a full revert makes sense.

I suggest we simply remove the flag emojis and specify country where needed, e.g., make Portugese into Portugese (PT).

---

For the record, the goal of the emojis was to specify the country code for countries that need it, not for the flags to wholly represent the language. For example, PT-BR would be Portugese 🇧🇷 and PT-PT would be Portugese 🇵🇹.

This also allowed us to get rid of the country code, as it's uglier to show the user Portugese (BR) instead of Portugese 🇧🇷, but @erciccione your comment makes it obvious that this is a flawed approach, as 1 country can have multiple languages (e.g., India with Hindi and Tamil).

[erciccione]

I suggest we simply remove the flag emojis and specify country where needed, e.g., make Portugese into Portugese (PT).

Agreed. I initially only reverted because i wanted to take down the flags from the website as soon as possible, but it's fair. I will update this PR tomorrow.

[wiz]

@erciccione I think you're a bit confused. Obviously flags do not represent languages, flags represent countries. In this case, we are using them to represent the country of certain country-specific locales, such as pt-PT and pt-BR, which is why the full language name is included to the left of the flag such as "Português 🇵🇹" - we are about to add the pt-BR locale and this PR is preparing the Bisq website for that new country-specific locale.

For international locales, such as English, we use the globe icon. If you want to suggest designating a certain country-specific locale as an international one, by replacing the flag with the globe icon, feel free, but this PR to revert an entire set of new localization features on the website makes no sense. NACK.

[m52go]

I think this is a good opportunity to clarify the longer-term goal of this internationalization initiative, as I don't think it was defined correctly at first.

Specifically: whether we're aiming to offer the site in multiple languages or multiple locales.

Focusing on language is fine if we're merely translating the whole website to another language, verbatim, with no differences in content and no considerations for localities. In that case, the changes discussed here make sense.

However, upon thinking through it more, the Bisq website might require a focus on locale instead. This would allow us to target geographic areas that map to markets on Bisq and specify payment methods and other items specific to particular markets.

For this reason, it might be better to have the drop-down stick to specifying countries, as most countries maintain their own currencies and banking conventions. Content can then be tailored to specific markets (e.g., show Japanese payment methods in the FAQs only to those who picked the Japanese locale).

We can use the predominant language in a particular currency market for now, which should work for the foreseeable future. Exception would be the EUR, but we can map it to the English version of the site for now, as we've been doing.

Thoughts?

The difference may seem subtle, but it informs how we handle i18n efforts across the board, including how we evaluate 242 and 243 (this PR).

If people are in agreement, then I think it makes sense to close this pull request and make another one to adjust the drop-down to fit locales more than languages, as described above.

[erciccione]

In this case, we are using them to represent the country of certain country-specific locales

@wiz
That's not better. Flags shouldn't be used to rappresent languages or local languages, that's not their point and can generate political coflicts. That's why the vast majority of the big projects around just don't use them.

this PR to revert an entire set of new localization features on the website makes no sense

The scope of this PR is only to remove the flags.

@m52go

Translators will always tend to translate in their locale language, but shouldn't be hardcoded and shouldn't be bonded with a country flag.

This would allow us to target geographic areas that map to markets on Bisq

As you point out after, this method is flawed, the English language cannot be bonded to one country, unless you use an infinity of en- locales, which would be unmaintainable and would make the life of translators much harder.

Anyway, this PR has a different scope, i think languages and locales shouldn't be associated with a flag, because it's a bad practice when it comes to localize a project, if i'm the minority and you still prefer to use them, then i will just close this PR.

About the second matter: I think it's not a good idea to work only with locales. In my experience, since translators contribute voluntarly and without obbligations, the best way would be to let translators come and translate in the language/locale they prefer if it makes sense (for example, i would avoid an en-US and an en-uk translation, would be a waste of resources) and then base everything according to the languages we have, not the structure we would like to see. This is a more flexible approach and avoid us ending up with a lot of locales that nobody needs and that will end up unmantained.

[wiz]

Flags shouldn't be used to rappresent languages or local languages

Again, the flags are not being used to represent languages, they are being used to represent countries. For example, if you click on 🇺🇸 you will see USA specific content, not English specific content.

i would avoid an en-US and an en-uk translation

Well yes, obviously. The difference between en-US and en-UK locales is not language, it will be country-specific content such as USA payment methods and UK specific payment methods. The generic "English" locale will not have any country-specific content, which is why it does not have a country's flag.

Flags shouldn't be used to rappresent languages, please take a look at http://www.flagsarenotlanguages.com.

I took a look at the site you recommended and indeed, under "Best practice for presenting languages" it does say that country-specific content does not apply:

[erciccione]

Again, the flags are not being used to represent languages, they are being used to represent countries.

Locales don't always match countries, you are assuming that you will always have a country matching a language, but that's not the case. Which flag would you use to represent Chinese Traditional or Chinese Simplified? And Kurdish?
Why would you even want to make that choice? Choosing one flag or another in these cases can create political issues. I don't understand why adopt an unusual approach that, beside looking nicer, have only potential disadvantages.

I think would be better to just adopt the most common and trouble-free approach, which is Language (language-code), but i also don't think it worth spending too much time discussing this particular issue, so i'm closing this PR. I only hope it won't come back to bite us in the ass.

[wiz]

Which flag would you use to represent Chinese Traditional or Chinese Simplified?

For the third time, we are not using flags to represent languages, we are using flags to represent the country in a country-specific locale. For generic non-country-specific locales, such as English, we use the globe icon to indicate the lack of country-specific localizations. A country-specific localized version of the Bisq website will contain country-specific information, such as payment method details.

As an example, for Japan we intend to have two locales: "Japanese 🇯🇵" and "English 🇯🇵" which will contain Japan-specific payment method information. Users from Japan will be automatically redirected to one of those 2 locales depending on the Accept-Language header their browser sends, and the result of looking up their IP address in a Geo-IP database.

Keep in mind, we are not the first people to localize software for the whole world, and we are simply following industry standards. For example, FedEx is an international company and their website also supports English and Japanese country-specific locales for Japan.

Please refer to this list of the ~150 preconstructed locales in Java, and you will see that many of them are indeed country-specific:

https://www.viralpatel.net/java-locale-list-tutorial/

[m52go]

@erciccione I realize you've now closed this pull request, but I meant to respond before.

Example:

Assume Spanish translation is complete, and locale-specific information is available for Mexico and Spain.

1. Focus on languages would yield a Spanish website readable by users in Mexico, Spain, and Argentina, but without the ability to show payment methods unique to any of those places.

2. Focus on locales yields a Spanish website that shows payment methods unique to Mexico (Spanish MXN) and Spain (Spanish EUR), but with no option for a Spanish website for those in Argentina (Spanish ARS).

I hope it's clear from the scenarios above that neither approach is ideal. But given the need for the Bisq website to provide locale-specific information, I find (2) more attractive. Absent this need, we could easily do (1) as you suggest...BTCPay does this, but their software works the same all around the world. Bisq doesn't.

I think the problem in (2) is solved by keeping a base translation of the English website without any locale-specific items, so that it can be deployed for new locales whenever needed. This is what translators are doing right now anyway.

As long as these base translations continue to be maintained, I don't think there will be too much extra work. If a locale-specific maintainer goes MIA, we can just revert to the base translation.

This may not be a perfect long-term solution, but I think it's sufficient for the foreseeable future.

[erciccione]

@wiz

I guess you keep missing my point. Using flags to rappresent country specific locales is not a good idea. Countries are not as defined as you are picturing them. So you have to choose between a "globe" flag and an arbitrary flag, which as i repeated many times, can create conflicts. I don't see a point in using a system that is not consistent and will only cause confusion (making people choose between different locales in many languages will only be confusing and mess up people who use Tor or a VPN). See below for an example of an ankward situation that could couse political problems, only because of the presence of a flag.

@m52go

I think why i want to avoid flags in this case is not clear, i'll make an example as well: An user is from north Kurdistan, Kurdish is not a single language, but changes depending by the area. Also, Kurdistan is an "unofficial" country, but sits on 4 different countries. Now, you have to choose which flag to use to reppresent Kurdish Kurmanji, which is spoken in northern kurdistan (southern turkey). That's both Turkish and Kurdish territory, but choosing one flag or another will piss off people from one country or the other and using a globe flag won't help you (beside being non consistent).
In your 2-points choice i will definitely choose the 1st. I understand it's not the optimal choice for bisq (since it has "country" specific form of payments), but it's safe and hussle-free.

---

To summarize my objections:

1. Flags should always be avoided when dealing with the localization of software. I had to mediate conflicts sparked because of disagreements between translators on how to use a single word. Introducing flags only adds another layer of potential conflicts that could be simply avoided.
2. I think moving to locales instead of languages will create more confusion than intended. As i said before, people using Tor or VPNs will have a worse UX. Users could also be confused by the unconsistent way languages + locales are shown, because this is open source, not FedEx, we will not have translations for all locales, not even close. Also, contributors come and go all the time and locales will have to be reverted to languages continuously (again, what's the point in creating a system you cannot keep consistent?).
3. The vast majority of Bisq users trade Monero (>90%), if we assume these people are more privacy-centric than other users, i don't think they will appreciate to be geo-tracked, even if assured that their data is not stored, doing so will give a feeling of "being watched". We can also assume a significant amount of privacy-aware users will use a VPN or Tor, which take us to the problem i spoke above (wrong locales and the need to switch).

This said: In my opinion using locales will be confusing for the reasons i listed above and i would pefer to avoid it, but i'm not strongly against it. I'm strongly against using flags.

I hope my objection is clear now, but as i said, i don't wish to push these arguments further. I'm the last arrived to the Bisq project, if "older" contributors prefer to introduce a new system and i'm the only one against, i will just accept the decision :)

[m52go]

@erciccione thanks for making your points thoroughly. Let's agree to disagree for now.

This conversation is on the public record, so we can always refer back to it if we need to.