lv_i18n includes unused pluralizing functions

[bryghtlabs-richard]

Small note for future improvement: when a translation does not have any plural strings, lv_i18n could avoid assigning the plural function pointer, to improve the final executable size

static const lv_i18n_lang_t de_lang = {
    .locale_name = "de",
    .singulars = de_singulars,

    //prevents removing de_plural_fn from the final executable
    .locale_plural_fn = de_plural_fn
};

[puzrin]

That was considered at the design phase regarding "added value."

In the real world, the percentage of plurals is quite small, so the proposed approach will increase complexity without notable benefits. Currently, plurals are in a separate list and do not affect the size of the list with singular. IMHO, that's a reasonable trade-off.

[bryghtlabs-richard]

Sorry, I don't think I explained it well enough.

I don't mean removing the plurals list, I only mean removing the assignment of the locale_plural_fn pointer when the plurals list for this language is empty. Hmm, perhaps we would need to remove the function too though, since they are per-language.

[puzrin]

I understood what you mean. My answer was probably not clear enough.

We have limited resources and can not optimize everything "just for fun." So, it is essential to answer the question:

• What is the added value of the proposed feature? For this case - how much data will be reduced in an actual project, and does it make sense?

IMHO, the real benefit is about zero because the percentage of plurals in the total number of phrases is small, and the total percentage of saved bytes will not be notable.

[bryghtlabs-richard]

For this case - how much data will be reduced in an actual project

In this project with 5 languages, it saves 320B, lv_i18n's instructions total 992B, so ~1/3 is of lv_i18n instructions are unreachable. The translated text is larger, but I can store the strings in slower external memory.

But, we also don't have all of our UI strings yet, so if we need pluralizing, we'd save nothing, and have the complexity. I'll close this for now, and perhaps we revisit later?