Skinning concept

[2stein]

yes, i agree. i only thought about translation.
the timespan is then fixed to HH:MM - HH:MM format. but imho that's fine.

 

[2stein]

i'm just thinking loud in this posting.
i had a look at UsageConfig.py

    def setDateStyles(configElement):
        dateStyles = {
            # dayfull            shortdayfull      daylong           dayshortfull   dayshort       daysmall    full           long           short
            _("%A %d %B %Y"): (_("%a %d %B %Y"), _("%a %d %b %Y"), _("%A %d %B"), _("%a %d %b"), _("%a %d"), _("%d %B %Y"), _("%d %b %Y"), _("%d %b")),
            _("%A %d. %B %Y"): (_("%a %d. %B %Y"), _("%a %d. %b %Y"), _("%A %d. %B"), _("%a %d. %b"), _("%a %d"), _("%d. %B %Y"), _("%d. %b %Y"), _("%d. %b")),
            _("%A %-d %B %Y"): (_("%a %-d %B %Y"), _("%a %-d %b %Y"), _("%A %-d %B"), _("%a %-d %b"), _("%a %-d"), _("%-d %B %Y"), _("%-d %b %Y"), _("%-d %b")),
            _("%A %-d. %B %Y"): (_("%a %-d. %B %Y"), _("%a %-d. %b %Y"), _("%A %-d. %B"), _("%a %-d. %b"), _("%a %-d"), _("%-d. %B %Y"), _("%-d. %b %Y"), _("%-d. %b")),
            _("%A %d-%B-%Y"): (_("%a %d-%B-%Y"), _("%a %d-%b-%Y"), _("%A %d-%B"), _("%a %d-%b"), _("%a %d"), _("%d-%B-%Y"), _("%d-%b-%Y"), _("%d-%b")),
            _("%A %-d-%B-%Y"): (_("%a %-d-%B-%Y"), _("%a %-d-%b-%Y"), _("%A %-d-%B"), _("%a %-d-%b"), _("%a %-d"), _("%-d-%B-%Y"), _("%-d-%b-%Y"), _("%-d-%b")),
            _("%A %d/%m/%Y"): (_("%a %d/%m/%Y"), _("%a %d/%m/%Y"), _("%A %d/%m"), _("%a %d/%m"), _("%a %d"), _("%d/%m/%Y"), _("%d/%m/%Y"), _("%d/%m")),
            _("%A %d.%m.%Y"): (_("%a %d.%m.%Y"), _("%a %d.%m.%Y"), _("%A %d.%m"), _("%a %d.%m"), _("%a %d"), _("%d.%m.%Y"), _("%d.%m.%Y"), _("%d.%m")),
            _("%A %-d/%m/%Y"): (_("%a %-d/%m/%Y"), _("%a %-d/%m/%Y"), _("%A %-d/%m"), _("%a %-d/%m"), _("%a %-d"), _("%-d/%m/%Y"), _("%-d/%m/%Y"), _("%-d/%m")),
            _("%A %-d.%m.%Y"): (_("%a %-d.%m.%Y"), _("%a %-d.%m.%Y"), _("%A %-d.%m"), _("%a %-d.%m"), _("%a %-d"), _("%-d.%m.%Y"), _("%-d.%m.%Y"), _("%-d.%m")),
            _("%A %d/%-m/%Y"): (_("%a %d/%-m/%Y"), _("%a %d/%-m/%Y"), _("%A %d/%-m"), _("%a %d/%-m"), _("%a %d"), _("%d/%-m/%Y"), _("%d/%-m/%Y"), _("%d/%-m")),
            _("%A %d.%-m.%Y"): (_("%a %d.%-m.%Y"), _("%a %d.%-m.%Y"), _("%A %d.%-m"), _("%a %d.%-m"), _("%a %d"), _("%d.%-m.%Y"), _("%d.%-m.%Y"), _("%d.%-m")),
            _("%A %-d/%-m/%Y"): (_("%a %-d/%-m/%Y"), _("%a %-d/%-m/%Y"), _("%A %-d/%-m"), _("%a %-d/%-m"), _("%a %-d"), _("%-d/%-m/%Y"), _("%-d/%-m/%Y"), _("%-d/%-m")),
            _("%A %-d.%-m.%Y"): (_("%a %-d.%-m.%Y"), _("%a %-d.%-m.%Y"), _("%A %-d.%-m"), _("%a %-d.%-m"), _("%a %-d"), _("%-d.%-m.%Y"), _("%-d.%-m.%Y"), _("%-d.%-m")),
            _("%A %B %d %Y"): (_("%a %B %d %Y"), _("%a %b %d %Y"), _("%A %B %d"), _("%a %b %d"), _("%a %d"), _("%B %d %Y"), _("%b %d %Y"), _("%b %d")),
            _("%A %B %-d %Y"): (_("%a %B %-d %Y"), _("%a %b %-d %Y"), _("%A %B %-d"), _("%a %b %-d"), _("%a %-d"), _("%B %-d %Y"), _("%b %-d %Y"), _("%b %-d")),
            _("%A %B-%d-%Y"): (_("%a %B-%d-%Y"), _("%a %b-%d-%Y"), _("%A %B-%d"), _("%a %b-%d"), _("%a %d"), _("%B-%d-%Y"), _("%b-%d-%Y"), _("%b-%d")),
            _("%A %B-%-d-%Y"): (_("%a %B-%-d-%Y"), _("%a %b-%-d-%Y"), _("%A %B-%-d"), _("%a %b-%-d"), _("%a %-d"), _("%B-%-d-%Y"), _("%b-%-d-%Y"), _("%b-%-d")),
            _("%A %m/%d/%Y"): (_("%a %m/%d/%Y"), _("%a %m/%d/%Y"), _("%A %m/%d"), _("%a %m/%d"), _("%a %d"), _("%m/%d/%Y"), _("%m/%d/%Y"), _("%m/%d")),
            _("%A %-m/%d/%Y"): (_("%a %-m/%d/%Y"), _("%a %-m/%d/%Y"), _("%A %-m/%d"), _("%a %-m/%d"), _("%a %d"), _("%-m/%d/%Y"), _("%-m/%d/%Y"), _("%-m/%d")),
            _("%A %m/%-d/%Y"): (_("%a %m/%-d/%Y"), _("%a %m/%-d/%Y"), _("%A %m/%-d"), _("%a %m/%-d"), _("%a %-d"), _("%m/%-d/%Y"), _("%m/%-d/%Y"), _("%m/%-d")),
            _("%A %-m/%-d/%Y"): (_("%a %-m/%-d/%Y"), _("%a %-m/%-d/%Y"), _("%A %-m/%-d"), _("%a %-m/%-d"), _("%a %-d"), _("%-m/%-d/%Y"), _("%-m/%-d/%Y"), _("%-m/%-d")),
            _("%A %Y %B %d"): (_("%a %Y %B %d"), _("%a %Y %b %d"), _("%A %B %d"), _("%a %b %d"), _("%a %d"), _("%Y %B %d"), _("%Y %b %d"), _("%b %d")),
            _("%A %Y %B %-d"): (_("%a %Y %B %-d"), _("%a %Y %b %-d"), _("%A %B %-d"), _("%a %b %-d"), _("%a %-d"), _("%Y %B %-d"), _("%Y %b %-d"), _("%b %-d")),
            _("%A %Y-%B-%d"): (_("%a %Y-%B-%d"), _("%a %Y-%b-%d"), _("%A %B-%d"), _("%a %b-%d"), _("%a %d"), _("%Y-%B-%d"), _("%Y-%b-%d"), _("%b-%d")),
            _("%A %Y-%B-%-d"): (_("%a %Y-%B-%-d"), _("%a %Y-%b-%-d"), _("%A %B-%-d"), _("%a %b-%-d"), _("%a %-d"), _("%Y-%B-%-d"), _("%Y-%b-%-d"), _("%b-%-d")),
            _("%A %Y/%m/%d"): (_("%a %Y/%m/%d"), _("%a %Y/%m/%d"), _("%A %m/%d"), _("%a %m/%d"), _("%a %d"), _("%Y/%m/%d"), _("%Y/%m/%d"), _("%m/%d")),
            _("%A %Y/%m/%-d"): (_("%a %Y/%m/%-d"), _("%a %Y/%m/%-d"), _("%A %m/%-d"), _("%a %m/%-d"), _("%a %-d"), _("%Y/%m/%-d"), _("%Y/%m/%-d"), _("%m/%-d")),
            _("%A %Y/%-m/%d"): (_("%a %Y/%-m/%d"), _("%a %Y/%-m/%d"), _("%A %-m/%d"), _("%a %-m/%d"), _("%a %d"), _("%Y/%-m/%d"), _("%Y/%-m/%d"), _("%-m/%d")),
            _("%A %Y/%-m/%-d"): (_("%a %Y/%-m/%-d"), _("%a %Y/%-m/%-d"), _("%A %-m/%-d"), _("%a %-m/%-d"), _("%a %-d"), _("%Y/%-m/%-d"), _("%Y/%-m/%-d"), _("%-m/%-d"))
        }

it defines lots of date-time formats. looking at the separators i see 4 different categories: 1: blank, 2: /, 3: -, 4: .
i assume that the formats with . are german (or are there other languages that have german style formats?). Those have several bugs.
so far i have fixed those bugs in the de.po translation (dont know if i caught all). but i think they should be fixed at the source.... in this matrix.

the next thing is a bigger question: from a concept point of view the matrix is ok (maybe the master key should be the language, but this would be a bigger change).
but the question if have is: why do these formats need to be translated (_(...))?
when i select a german format the list behind should be used as is and dont need translation.
when i select an english format and have german language i dont want the formats to be translated into german because i selected an english format because i do want english format und not german.
so imho all translations should be removed. any comments?

 

[twol]

i'm just thinking loud in this posting.
i had a look at UsageConfig.py

    def setDateStyles(configElement):
        dateStyles = {
            # dayfull            shortdayfull      daylong           dayshortfull   dayshort       daysmall    full           long           short
            _("%A %d %B %Y"): (_("%a %d %B %Y"), _("%a %d %b %Y"), _("%A %d %B"), _("%a %d %b"), _("%a %d"), _("%d %B %Y"), _("%d %b %Y"), _("%d %b")),
            _("%A %d. %B %Y"): (_("%a %d. %B %Y"), _("%a %d. %b %Y"), _("%A %d. %B"), _("%a %d. %b"), _("%a %d"), _("%d. %B %Y"), _("%d. %b %Y"), _("%d. %b")),
            _("%A %-d %B %Y"): (_("%a %-d %B %Y"), _("%a %-d %b %Y"), _("%A %-d %B"), _("%a %-d %b"), _("%a %-d"), _("%-d %B %Y"), _("%-d %b %Y"), _("%-d %b")),
            _("%A %-d. %B %Y"): (_("%a %-d. %B %Y"), _("%a %-d. %b %Y"), _("%A %-d. %B"), _("%a %-d. %b"), _("%a %-d"), _("%-d. %B %Y"), _("%-d. %b %Y"), _("%-d. %b")),
            _("%A %d-%B-%Y"): (_("%a %d-%B-%Y"), _("%a %d-%b-%Y"), _("%A %d-%B"), _("%a %d-%b"), _("%a %d"), _("%d-%B-%Y"), _("%d-%b-%Y"), _("%d-%b")),
            _("%A %-d-%B-%Y"): (_("%a %-d-%B-%Y"), _("%a %-d-%b-%Y"), _("%A %-d-%B"), _("%a %-d-%b"), _("%a %-d"), _("%-d-%B-%Y"), _("%-d-%b-%Y"), _("%-d-%b")),
            _("%A %d/%m/%Y"): (_("%a %d/%m/%Y"), _("%a %d/%m/%Y"), _("%A %d/%m"), _("%a %d/%m"), _("%a %d"), _("%d/%m/%Y"), _("%d/%m/%Y"), _("%d/%m")),
            _("%A %d.%m.%Y"): (_("%a %d.%m.%Y"), _("%a %d.%m.%Y"), _("%A %d.%m"), _("%a %d.%m"), _("%a %d"), _("%d.%m.%Y"), _("%d.%m.%Y"), _("%d.%m")),
            _("%A %-d/%m/%Y"): (_("%a %-d/%m/%Y"), _("%a %-d/%m/%Y"), _("%A %-d/%m"), _("%a %-d/%m"), _("%a %-d"), _("%-d/%m/%Y"), _("%-d/%m/%Y"), _("%-d/%m")),
            _("%A %-d.%m.%Y"): (_("%a %-d.%m.%Y"), _("%a %-d.%m.%Y"), _("%A %-d.%m"), _("%a %-d.%m"), _("%a %-d"), _("%-d.%m.%Y"), _("%-d.%m.%Y"), _("%-d.%m")),
            _("%A %d/%-m/%Y"): (_("%a %d/%-m/%Y"), _("%a %d/%-m/%Y"), _("%A %d/%-m"), _("%a %d/%-m"), _("%a %d"), _("%d/%-m/%Y"), _("%d/%-m/%Y"), _("%d/%-m")),
            _("%A %d.%-m.%Y"): (_("%a %d.%-m.%Y"), _("%a %d.%-m.%Y"), _("%A %d.%-m"), _("%a %d.%-m"), _("%a %d"), _("%d.%-m.%Y"), _("%d.%-m.%Y"), _("%d.%-m")),
            _("%A %-d/%-m/%Y"): (_("%a %-d/%-m/%Y"), _("%a %-d/%-m/%Y"), _("%A %-d/%-m"), _("%a %-d/%-m"), _("%a %-d"), _("%-d/%-m/%Y"), _("%-d/%-m/%Y"), _("%-d/%-m")),
            _("%A %-d.%-m.%Y"): (_("%a %-d.%-m.%Y"), _("%a %-d.%-m.%Y"), _("%A %-d.%-m"), _("%a %-d.%-m"), _("%a %-d"), _("%-d.%-m.%Y"), _("%-d.%-m.%Y"), _("%-d.%-m")),
            _("%A %B %d %Y"): (_("%a %B %d %Y"), _("%a %b %d %Y"), _("%A %B %d"), _("%a %b %d"), _("%a %d"), _("%B %d %Y"), _("%b %d %Y"), _("%b %d")),
            _("%A %B %-d %Y"): (_("%a %B %-d %Y"), _("%a %b %-d %Y"), _("%A %B %-d"), _("%a %b %-d"), _("%a %-d"), _("%B %-d %Y"), _("%b %-d %Y"), _("%b %-d")),
            _("%A %B-%d-%Y"): (_("%a %B-%d-%Y"), _("%a %b-%d-%Y"), _("%A %B-%d"), _("%a %b-%d"), _("%a %d"), _("%B-%d-%Y"), _("%b-%d-%Y"), _("%b-%d")),
            _("%A %B-%-d-%Y"): (_("%a %B-%-d-%Y"), _("%a %b-%-d-%Y"), _("%A %B-%-d"), _("%a %b-%-d"), _("%a %-d"), _("%B-%-d-%Y"), _("%b-%-d-%Y"), _("%b-%-d")),
            _("%A %m/%d/%Y"): (_("%a %m/%d/%Y"), _("%a %m/%d/%Y"), _("%A %m/%d"), _("%a %m/%d"), _("%a %d"), _("%m/%d/%Y"), _("%m/%d/%Y"), _("%m/%d")),
            _("%A %-m/%d/%Y"): (_("%a %-m/%d/%Y"), _("%a %-m/%d/%Y"), _("%A %-m/%d"), _("%a %-m/%d"), _("%a %d"), _("%-m/%d/%Y"), _("%-m/%d/%Y"), _("%-m/%d")),
            _("%A %m/%-d/%Y"): (_("%a %m/%-d/%Y"), _("%a %m/%-d/%Y"), _("%A %m/%-d"), _("%a %m/%-d"), _("%a %-d"), _("%m/%-d/%Y"), _("%m/%-d/%Y"), _("%m/%-d")),
            _("%A %-m/%-d/%Y"): (_("%a %-m/%-d/%Y"), _("%a %-m/%-d/%Y"), _("%A %-m/%-d"), _("%a %-m/%-d"), _("%a %-d"), _("%-m/%-d/%Y"), _("%-m/%-d/%Y"), _("%-m/%-d")),
            _("%A %Y %B %d"): (_("%a %Y %B %d"), _("%a %Y %b %d"), _("%A %B %d"), _("%a %b %d"), _("%a %d"), _("%Y %B %d"), _("%Y %b %d"), _("%b %d")),
            _("%A %Y %B %-d"): (_("%a %Y %B %-d"), _("%a %Y %b %-d"), _("%A %B %-d"), _("%a %b %-d"), _("%a %-d"), _("%Y %B %-d"), _("%Y %b %-d"), _("%b %-d")),
            _("%A %Y-%B-%d"): (_("%a %Y-%B-%d"), _("%a %Y-%b-%d"), _("%A %B-%d"), _("%a %b-%d"), _("%a %d"), _("%Y-%B-%d"), _("%Y-%b-%d"), _("%b-%d")),
            _("%A %Y-%B-%-d"): (_("%a %Y-%B-%-d"), _("%a %Y-%b-%-d"), _("%A %B-%-d"), _("%a %b-%-d"), _("%a %-d"), _("%Y-%B-%-d"), _("%Y-%b-%-d"), _("%b-%-d")),
            _("%A %Y/%m/%d"): (_("%a %Y/%m/%d"), _("%a %Y/%m/%d"), _("%A %m/%d"), _("%a %m/%d"), _("%a %d"), _("%Y/%m/%d"), _("%Y/%m/%d"), _("%m/%d")),
            _("%A %Y/%m/%-d"): (_("%a %Y/%m/%-d"), _("%a %Y/%m/%-d"), _("%A %m/%-d"), _("%a %m/%-d"), _("%a %-d"), _("%Y/%m/%-d"), _("%Y/%m/%-d"), _("%m/%-d")),
            _("%A %Y/%-m/%d"): (_("%a %Y/%-m/%d"), _("%a %Y/%-m/%d"), _("%A %-m/%d"), _("%a %-m/%d"), _("%a %d"), _("%Y/%-m/%d"), _("%Y/%-m/%d"), _("%-m/%d")),
            _("%A %Y/%-m/%-d"): (_("%a %Y/%-m/%-d"), _("%a %Y/%-m/%-d"), _("%A %-m/%-d"), _("%a %-m/%-d"), _("%a %-d"), _("%Y/%-m/%-d"), _("%Y/%-m/%-d"), _("%-m/%-d"))
        }

it defines lots of date-time formats. looking at the separators i see 4 different categories: 1: blank, 2: /, 3: -, 4: .
i assume that the formats with . are german (or are there other languages that have german style formats?). Those have several bugs.
so far i have fixed those bugs in the de.po translation (dont know if i caught all). but i think they should be fixed at the source.... in this matrix.

the next thing is a bigger question: from a concept point of view the matrix is ok (maybe the master key should be the language, but this would be a bigger change).
but the question if have is: why do these formats need to be translated (_(...))?
when i select a german format the list behind should be used as is and dont need translation.
when i select an english format and have german language i dont want the formats to be translated into german because i selected an english format because i do want english format und not german.
so imho all translations should be removed. any comments?This was one of the many

This was one of the many IanSav time/date/language updates before he moved to OpenATV and at the time the updates came fast and furious and were difficult to keep up with for me (trying to convert code to python3) and probably also Huevos.
So probably a good time to review!

original commit here........

Add selectable date / time infrastructure (#79) · OpenViX/enigma2@8071b86

* Allow use of font aliases This change allows skin developers to use font aliases as well as normal fonts in skin based TemplatedMultiContent converter structures. In the past users could on...

github.com

 

[2stein]

in the meantime i just removed the _(...) from the dict... and all the date/times of epgs are messed up.
so, its not that easy... but very very complex.
so i'll better keep my fingers off

 

[Huevos]

They should be translated. It is the key that is not translated.

 

[2stein]

well, the key _("%A %d %B %Y"): is also translated or do you mean a different key?
there must be something really flawed when you remove translation and it screws up.

 

[Huevos]

Maybe we should continue this away from the public area.

I recommend you read the full 411 post DateTime proposal thread.

And the github commit history.

 

[2stein]

yes, good idea.
i dont want to badmounth the work of others. this concept is really very flexible and with the requirement to stay backward compatible added complexity.
i would have to spend much more time to really understand it. and when changes are done a lot of testing would be required to make sure everything still works.

on the other hand i'm not sure whether all this flexibility/complexity is really required. i havent changed anything in the custom settings and run with all defaults. the bugs in the german formats were all fixed in the translation (plus one converter change). so i'm happy for now.

my conclusion: a concept change would be a hercules task and i'm not sure whether the effort would be justified. again: i was probably a little naive to assume this could be simplified quickly.

 

[Huevos]

My conclusion is that centralising the date/time stuff was a good idea, but I would have like to have seen a simple solution. I guess this is what happens when non-coders have permission to merge pull requests.

 

[2stein]

i fully agree with you. i like to be reviewed before merge... 4 eyes see more than 2.

 

[2stein]

i dont know what you guys think about ai. but i wanted to let you know what claude opus' assessment of UsageConfig.py is. it basically confirms my "feelings". but i'm not suggesting to change anything based on this.


# Assessment: Translatable strftime Date/Time Format Strings in UsageConfig.py
## The Core Design
The system uses `_()` (gettext) to wrap **strftime format strings** that serve as both config selection keys and format strings passed to `strftime()`. When the user picks `_("%A %-d %B %Y")`, that translated string is stored as the config value and later passed verbatim to `strftime()`.
Eight subordinate date fields (`shortdayfull`, `daylong`, `dayshortfull`, `dayshort`, `daysmall`, `full`, `long`, `short`) and two subordinate time fields (`mixed`, `short`) are derived from the primary selection via large lookup dictionaries — also with every key and value wrapped in `_()`.
---
## Fundamental Problem: strftime Strings Should Not Be Translatable
Wrapping strftime format strings in `_()` is an **anti-pattern** with several failure modes:
### 1. Translations must be valid strftime — but translators aren't programmers
Any `.po` translator who makes even a small error — an extra space, a wrong directive, a missing `%` — silently produces corrupt date output or a runtime crash. For example, German `de.po` translates:
```
"%A %-d %B %Y" → "%A, %-d. %B %Y"
```
This works, but nothing enforces it. A translator could easily break it.
### 2. Untranslated entries (empty `msgstr`) silently work — but fuzzy entries can break
When `msgstr` is empty, gettext returns the `msgid` (the English default) — safe. But many `.po` files contain **fuzzy** translations (e.g., Swedish changes `%-d` to `%d`, Danish removes the day name). Fuzzy entries may or may not be activated depending on the `msgfmt` compilation flags, creating unpredictable behavior per locale.
### 3. The lookup dictionaries are fragile across translations
In `setDateStyles()` (lines 489–538), every key and value is wrapped in `_()`:
```python
dateStyles = {
_("%A %d %B %Y"): (_("%a %d %B %Y"), _("%a %d %b %Y"), ...),
_("%A %-d %B %Y"): (_("%a %-d %B %Y"), _("%a %-d %b %Y"), ...),
...
}
style = dateStyles.get(configElement.value, ((_("Invalid")) * 8))
```
This depends on **all related format strings being translated consistently**. If a translator translates the `configElement.value` key (`"%A %-d %B %Y"` → `"%A, %-d. %B %Y"`) but does **not** translate the corresponding dictionary key the same way, the lookup misses and all 8 derived fields get set to `"Invalid"`. There are **30 keys × 8 values = 240 format strings** in `dateStyles` alone that must remain in perfect mutual agreement per locale.
### 4. Dictionary key collisions from translation
Two distinct English format strings could be translated to the same string in another language, causing a **silent dictionary key collision** and loss of an entry. For example, if a translator maps both `"%A %d %B %Y"` and `"%A %-d %B %Y"` to the same German string `"%A, %d. %B %Y"`, one entry silently shadows the other.
### 5. Saved config values become locale-dependent
The stored config values are the **translated** strftime strings. If a user changes their system locale, the old stored value (in the previous locale's translation) will no longer match any of the new locale's choice keys. The config will silently fall back to a default or keep the stale translated string, which might not match any entry in the new `dateStyles` dictionary.
### 6. The config selection UI shows strftime strings as choice keys
In `ConfigSelection`, the first element of each tuple is both the **stored value** and (if no second element were provided) the displayed text. Here the second element (the human-readable label like `"Dayname D Month Year"`) is what the user sees. But the stored value is still the translated strftime string — this means the persistent config file contains locale-specific strftime strings, making config files non-portable between locales.
---
## Specific Code Issues
### Redundant `ConfigText` defaults are immediately overwritten
Lines 464–486 define 8 `ConfigText` items (e.g., `config.usage.date.shortdayfull`) with translated defaults. But line 540 adds a notifier to `dayfull` that **immediately overwrites** all 8 of them from `setDateStyles()`. The defaults serve no purpose beyond initial flash before the notifier fires.
### `setDateStyles` fallback produces invalid output
```python
style = dateStyles.get(configElement.value, ((_("Invalid")) * 8))
```
The fallback `_("Invalid") * 8` repeats the **string** "Invalid" 8 times (string multiplication), producing `"InvalidInvalidInvalidInvalidInvalidInvalidInvalidInvalid"` — a single long string, not a tuple of 8 strings. When subsequently indexed as `style[0]`, `style[1]`, etc., it yields individual **characters**, not the word "Invalid". Should be:
```python
style = dateStyles.get(configElement.value, ((_("Invalid"),) * 8))
```
Same bug at line 577 and line 675:
```python
style = timeStyles.get(configElement.value, ((_("Invalid")) * 2)) # "InvalidInvalid"
style = dateDisplayStyles.get(configElement.value, ((_("Invalid")) * 2))
```
### Template encoding with special characters is brittle
The VFD display template system uses placeholder characters `_`, `=`, `+` within strftime-adjacent strings:
```python
_("%d+%b_") # + and _ are replaced later
```
These magic characters could collide with translations or strftime output. The encoding scheme (`_` → space, `=` → `-` or empty, `+` → space or empty) is undocumented and fragile.
---
## Contrast with `dateFormatAbout` (the correct approach)
Line 422 defines a different date config:
```python
config.usage.date.dateFormatAbout = ConfigSelection(
default="%(day)s-%(month)s-%(year)s",
choices=[
("%(day)s-%(month)s-%(year)s", _("DD-MM-YYYY")),
("%(month)s-%(day)s-%(year)s", _("MM-DD-YYYY")),
("%(year)s-%(month)s-%(day)s", _("YYYY-MM-DD"))
]
)
```
This is the **correct pattern**: raw format strings as untranslated keys, with only the human-readable labels translated. The stored value is always `"%(day)s-%(month)s-%(year)s"` regardless of locale.
---
## Summary of Issues
| Issue | Severity | Affected Lines |
|---|---|---|
| strftime strings wrapped in `_()` make stored values locale-dependent | **Design** | 431–463, 544–560, 608–627 |
| Lookup dictionaries fail if translations are inconsistent | **Critical** | 489–538, 568–579, 653–679 |
| `_("Invalid") * N` is string multiplication, not tuple | **Bug** | 537, 577, 675 |
| Translators can silently produce invalid strftime output | **Fragile** | All `.po` files |
| Config files non-portable across locale changes | **Design** | All stored date/time values |
| Key collisions possible if two English formats translate identically | **Latent bug** | 489–538, 653–679 |
| VFD template `+`, `=`, `_` encoding is undocumented/fragile | **Maintainability** | 629–651 |
| 30×8 + 8×2 + 17×2 = 290 hand-enumerated translatable strings | **Complexity** | 489–538, 568–579, 653–679 |
---
## Recommended Approach
The strftime format strings should be **plain, untranslated keys** (like `dateFormatAbout` does). The derived formats should be computed programmatically (e.g., replace `%A` → `%a`, drop `%Y`, replace `%B` → `%b`) rather than enumerated in massive lookup tables. This would eliminate all six issue categories above and reduce ~300 lines to ~30.

 

[Huevos]

The crux of its argument is "## Fundamental Problem: strftime Strings Should Not Be Translatable ... translators aren't programmers".

The reality is translation strings contain formatting. If they didn't we would end up with translation units that are shorter than one sentence and impossible to translate into multiple languages.

 

[2stein]

yes, i think we should close this discussion. when formatting problems show up, we can do a small fix rather than a huge change. for a conceptual change we first would have to come up with a good one and then the implementation would probably be a lot of effort.

 

[Huevos]

So to me it does not make sense:

1. User chooses a date format.
2. User chooses a different language.
3. Date format is no longer what the user selected.

This is what happens when monolingual people associate formats to languages.

The same happens when people use flags to represent languages without understanding a flag is national and a language is not.

 

[2stein]

yes, it's complex. for a while i thought that the '." date format is the only valid format for germany. now i learned that the '-' format is also valid according to DIN.
and '.' format is not only used in germany but also in finnland (beside others).
i searched whether there is a ready to use lib or something that already handles the complexity... but i couldnt find one.

 

[Waseem]

I have VU+ UNO 4K SE (Openatv-8.0.0-beta ... Skin copper-fhd) ... I couldn't install lcd4linux in any way. I just want the tuner information (signal) to appear on the front LCD screen. What's the solution?

 

[Huevos]

This is openvix forum. For openatv questions you should probably ask on their forum.