i18n(ar): improve Arabic translations

[jermanuts]

No description provided.

[zefr0x]

This is a (partial) duplicate of #159. As far as I can see, there is nothing new or improved from #159

[jermanuts]

hey, @zefr0x good to see you here. I didn't realize that there was a PR already, but I find the excessive use of diacritics (which is good in writings) not good for software use as it might be harder to read or unnecessary. You can check KDE and GNOME translations.

[zefr0x]

hey, @zefr0x good to see you here. I didn't realize that there was a PR already, but I find the excessive use of diacritics (which is good in writings) not good for software use as it might be harder to read or unnecessary. You can check KDE and GNOME translations.

If it was harder to read, then it should be a font or rendering issue that should be solved by using a better font or fixing the renderer. Otherwise it should be considered normal Arabic.
Both KDE and GNOME use default fonts that render diacritics broken or hard to read, since it mostly just put them without consideration for context or sizes of the surroundings and sometimes you might see multiple diacritics very close to the point of being merged together. For example, the Amiri font does a better job for diacritics, but some might consider it not suitable for UI, and it is unless we made it bigger.

I'm not sure if this was a good argument, but AFAIK in the Chinese language there are more details in the characters themself, so if there was a problem in reading them, I think it is a common issue that should be solved in the font level.

I believe that we should maintain the usage of Quranic Arabic in ar, but we can also have another variant of Arabic without diacritics. Currently, we just have country variants like ar_SA or ar_QA which is a naive design by who created the localisation system, so I would like to see more relevant variants.

Alternatively (which I’m in favour of), we may have an accessibility option to remove diacritics except maybe Shaddah, for easier read. However, I'm not sure of edge cases and how should they be handled here.

---

As a conclusion, I believe that we should reach this from the fonts and the design of the localisation system first, before considering just removing diacritics as a solution.

If nothing worked, then I don't have problem with removing most of diacritics.

[jermanuts]

@zefr0x But you do realize how terrible it will look now currently when majority of translation is without diacritics and a few has diacritics ruining UX? For now I think it is better to have it without diacritics until there's a consensus on how COSMIC will handle this situation.

Also, the suggested accessibility feature doesn't make sense as some diacritics is very much needed as sometimes without it, the whole word meaning/context will change completely. (I include these crucial diacritics in my translations).

Perhaps there should be a better way to continue this discussion instead of this PR? An issue on a repo for all localization matters?

[mmstick]

We're already accepting contributions with diacritics so it shouldn't be an issue. Our text renderer handles these quite well. If visibility is an issue, there is the option of increasing display scale to accommodate. We fully support fractional scaling in our toolkit.

[jermanuts]

@mmstick

you do realize how terrible it will look now currently when majority of translation is without diacritics and a few has diacritics ruining UX?

The issue is whether we want to diacriticize every single word or just the ones necessary

[zefr0x]

For now I think it is better to have it without diacritics until there's a consensus on how COSMIC will handle this situation.

I believe that we have a space during the beta phase before reaching stable. We can easily revert from having diacritics to not having them, but the reverse would take more time.

Perhaps there should be a better way to continue this discussion instead of this PR? An issue on a repo for all localization matters?

I wouldn't prefer to split the translation effort to work on both diacritics and non-diacritics variants. However, if there was no consensus, should the issue of having special local variants (other than the country ones in ISO 3166-1 alpha-2) concerns COSMIC or Project Fluent? @mmstick