[DRAFT] fix(NcTimezonePicker): new design with l10n

[ShGKme]

☑️ Resolves

• Based on perf(NcTimezonePicker): use Intl to reduce self-size from 206kb to 2kb  #7522
• Adding more information to each timezone, including l10n

🖼️ Screenshots

🏚️ Before	🏡 After (EN)

DE	UA	FR	AR

🏁 Checklist

• ⛑️ Tests are included or are not applicable
• 📘 Component documentation has been extended, updated or is not applicable
• 2️⃣ Backport to stable8 for maintained Vue 2 version or not applicable

[jancborchardt]

Very very nice @ShGKme ! Is it possible to cut the " Time" text, as it is very repeated.

[ShGKme]

Very very nice @ShGKme ! Is it possible to cut the " Time" text, as it is very repeated.

In a general case — no. It is a browser-provided timezone string, and it is different for every language. For example, "heure : " in French or "час:" in Ukrainian. It is already a short variant.

[ShGKme]

Also, every part (except for timezoneID like "Europe/Berlin") adds ~50ms component init time 😶

• Shot name "Germany Time" - +50ms
• Offset value "GMT+1" - +50ms
• Local current time "10:10 PM" - +50ms
• Actual offset for sorting - +50ms

So removing any part makes the component faster :D

Optimised as much as possible to have the init happen only once and only when needed

[jancborchardt]

Also, every part (except for timezoneID like "Europe/Berlin") adds ~50ms component init time 😶

Oof :O bummer, would be really nice to stay under 100ms.

But if we cut e.g. the offset value, and the technical name, then it's a bit less nicely usable and searchable.

[ShGKme]

@jancborchardt Maybe this would be useful — examples of available formats in different languages:

Link

[jancborchardt]

@ShGKme bit of a mess … in English, shortGeneric is a bit better, but in German that’s quite bad. (Just showing "MEZ" a bunch.)

If we just go for one, is it possible to say that e.g. in English and others we use "shortGeneric", and in German we use "Timezone ID"? Sorry to overcomplicate it, but the system doesn’t seem to make it simple. :\

[ShGKme]

is it possible

Yes, but the question will be - for which languages do we want an exception

and in German we use "Timezone ID"

ID is a technical non-translated value. Maybe at least a long name? Or City + Short?

MEZ (Berlin)

[jancborchardt]

@ShGKme but if we use shortGeneric + city, we still use 2*50ms, right? So maybe it's fine to just go with your pull request as is, and then iterating based off that if we see specific issues?

[kra-mo]

From the visual side, I like this, but what belongs to what can be a bit confusing. Could separators be added between the items? Or alternatively just the top/bottom padding increased (although that compromises on information density).

[kra-mo]

although that compromises on information density

On second thought, and after playing with it a bit, just bumping the top/bottom padding might be the better option anyway as for separators, we would need to increase the padding slightly too and they actually introduce a bit of noise themselves.

[kra-mo]

Separators only for reference

[ShGKme]

From the visual side, I like this, but what belongs to what can be a bit confusing. Could separators be added between the items? Or alternatively just the top/bottom padding increased (although that compromises on information density).

Technically - yes, but I'd avoid such changes in this PR.

We have this style in popovers list items in all the selecting (incl. tag select, user select), action menus, contenteditable autocomplete and etc.

If we want to change the style of the items, I'd insist on changing them in the design, not in a timezone picker specifically...

Here I can propose to increase the internal block padding.

[kra-mo]

Here I can propose to increase the internal block padding.

Yes, I can agree with that

[jancborchardt]

Am also good with just a little added padding. :)