Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

@ariel-lindemann I think English should always be the first.

@Uri-Tauber makes sense. I've adjusted it accordingly. Would appreciate imput on sorting non ASCII and non latin characters. I see three pahts:

• leave as is (sorted by unicode values)
• sort latin modified characters with unmodified ones and non-latin separately (C with Č)
• find a way to logically transliterate non-latin characters internally for sorting (so cyrillic Р gets sorted as latin R)

@ariel-lindemann I think this might be getting overcomplicated. At the moment, the order is determined by the _order key in each YAML file. The simplest approach would be to update the Python script to ignore that key and instead generate a sorted list based on your desired logic (PyICU could probably help here).

This way, you avoid adding extra code to the firmware and keep the sorting logic contained in the compilation.

@Uri-Tauber makes sense. I've adjusted it accordingly. Would appreciate imput on sorting non ASCII and non latin characters. I see three pahts:

• leave as is (sorted by unicode values)
• sort latin modified characters with unmodified ones and non-latin separately (C with Č)
• find a way to logically transliterate non-latin characters internally for sorting (so cyrillic Р gets sorted as latin R)

just sort it manually? There are not that many languages to introduce complicated logic. Feels like just _order key needs to be updated in desired sort order

@ariel-lindemann I think this might be getting overcomplicated. At the moment, the order is determined by the _order key in each YAML file. The simplest approach would be to update the Python script to ignore that key and instead generate a sorted list based on your desired logic (PyICU could probably help here).

This way, you avoid adding extra code to the firmware and keep the sorting logic contained in the compilation.

@Uri-Tauber that's what I'm already doing. All the sorting is being done in python so at compile time the order is already set.
I've decided for the middle option which i think is balanced between intuitive and not as complicated to implement

Thank you for the input!

@Uri-Tauber makes sense. I've adjusted it accordingly. Would appreciate imput on sorting non ASCII and non latin characters. I see three pahts:

• leave as is (sorted by unicode values)
• sort latin modified characters with unmodified ones and non-latin separately (C with Č)
• find a way to logically transliterate non-latin characters internally for sorting (so cyrillic Р gets sorted as latin R)

just sort it manually? There are not that many languages to introduce complicated logic. Feels like just _order key needs to be updated in desired sort order

@osteotek the idea is that the script would do the sorting. Otherwise, each time a new translation comes in, the translator would have to change the indexes manually which he might forget and is error prone anyway.

This way it is done inside the script which is used anyway when adding a new language. And recently there have been many new translations coming in (#1049, #987, #1065) and I anticipate there will be more (eg Italian, Chinese, Arabic, Hebrew). So I think it makes sense to have this automated.

So there are really no costs:

• no additional burden for the translators
• no calculations at runtime (everything is calculated before compilation)

Ok, I'm fine with that approach. Maybe remove _order key from language files then?

I'm personally fine with Cyrillic languages being at the end of the list

Another idea: instead of sorting on language strings directly, sort on their language keys (uk, ru, en, it, etc). This would solve problem with diacritics and Cyrillic languages

Ok, I'm fine with that approach. Maybe remove _order key from language files then?

I'm personally fine with Cyrillic languages being at the end of the list

@osteotek we can't remove the _order key without affecting the composition of the enum and breaking backwards compatibility. Because if we sorted directly on the enum, once a new language is added and the user upgrades, he may find the UI in a language he doesnt understand. That's why the script is creating the SORTED_LANGUAGE_INDICES array instead of moditfying the enum.

Another idea: instead of sorting on language strings directly, sort on their language keys (uk, ru, en, it, etc). This would solve problem with diacritics and Cyrillic languages

I came here to write a similar idea.
Basically, the most important part is determinated order, so if we use a new value that represants language codes (uk, en, etc) or even existing _language_code, it'll be OK because the order always follows the same rules

Another idea: instead of sorting on language strings directly, sort on their language keys (uk, ru, en, it, etc). This would solve problem with diacritics and Cyrillic languages

I've tried this locally, with the _language_code key and the resulting order is this:

´English, Català, Čeština, Français, Deutsch, Português (Brasil), Română, Русский, Español, Svenska´

So basically it's sorted by the english translation, which seems a bit arbitraty. But maybe we should change the key to the ISO language code so that would make things clearer

I propose we use ISO language designations in _language_code. I think that is most straight forward

Another idea: instead of sorting on language strings directly, sort on their language keys (uk, ru, en, it, etc). This would solve problem with diacritics and Cyrillic languages

I've tried this locally, with the _language_code key and the resulting order is this:

´English, Català, Čeština, Français, Deutsch, Português (Brasil), Română, Русский, Español, Svenska´

So basically it's sorted by the english translation, which seems a bit arbitraty. But maybe we should change the key to the ISO language code so that would make things clearer

All sorting methods would seem arbitrary in one way or another. This one looks ok to me

Another idea: instead of sorting on language strings directly, sort on their language keys (uk, ru, en, it, etc). This would solve problem with diacritics and Cyrillic languages

I've tried this locally, with the _language_code key and the resulting order is this:

´English, Català, Čeština, Français, Deutsch, Português (Brasil), Română, Русский, Español, Svenska´

So basically it's sorted by the english translation, which seems a bit arbitraty. But maybe we should change the key to the ISO language code so that would make things clearer

Realistically, I see two ways to do it, either use ISO codes or sort separatly by alphabet type, because the approach with translation is confusing, IMO

I've implemented it with ISO codes now and also wrote it in the docs. I think this is the most standardized we can get.

Thank you for your constructive input!

the order is now: English, Català, Čeština, Deutsch, Español, Français, Português (Brasil), Română, Русский, Svenska