nextcloud-libraries
[DRAFT] fix(NcTimezonePicker): new design with l10n
โ๏ธ Resolves
- Based on https://github.com/nextcloud-libraries/nextcloud-vue/pull/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
stable8for maintained Vue 2 version or not applicable
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.
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
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.
@jancborchardt Maybe this would be useful โ examples of available formats in different languages:
@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. :\
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)
@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?
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).
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.
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.
Here I can propose to increase the internal block padding.
Yes, I can agree with that