Language Support Status
The GNOME support status of a language is determined by the percentage of the GNOME environment translated.
A language is said to be Supported if it is at least 80% translated, Partially Supported if it is at least 50% translated, or Not Supported otherwise.
Today
Counting the translated percentage is done in the simplest manner of "number of translated strings / total number of translatable strings".
Whats wrong?
There is no balance between the actual influence of a certain module on the GNOME experience and its influence on the translated percentage.
A loud example is the GNOME weather applet locations module. These locations strings appear in exactly one list view in the preferences window of the weather applet. Clearly they have a little impact on a user using a localized GNOME session. However, the locations strings count for 10% of the translated desktop. Lets say a language is all translated but the locations strings, I think it is safe to say it is 99% translated. But in the current situation it would have been 90%.
A minor example is Evolution which is an important part of the desktop for all Users/Developers/Administrators. Though important, the current 15% count of the translated desktop seems too much.
Why now?
With the addition of the GNOME Developer Tools package and the increased amount of translatable strings, the translation teams want to focus on what (they think) to be more important. Some would prefer to skip Anjuta or GtkProperties in favor of translating more commonly used applications/applets (For example: file-roller, bug-buddy, deskbar-applet, evince, ... ) which are easier to handle as they may have much less to translate. In such a case though the Desktop would yield a better localized experience but the percentage count would not grow as much as you would expect.
What can we do?
YairHershkovitz proposal:
- Generally I agree with the idea of the 50%/80% system. But I also think that the current way of counting is not good enough. Not in the sense of why do we count a certain module, but how to count it.
- The motivation for my proposal are two modules: evolution and libgweather-locations. libgweather-locations has a really really minor influence on the experience of a user using a localized desktop, yet it counts for 10% of the GNOME desktop translation - this is absurd. Evolution in contract to the previous is an important part of the desktop experience (for all "normal"/developers/administrators/... users). Evolution counts for 12% of the translations. But, is Evolution more important then gnome-panel (1.5%), metacity+libwnck (3%), nautilus (3%) or epiphany (2%) ?
- This leads me to believe that instead of counting total strings we should use weighted counting. The simplest weight could be uniformly on all modules, say 'n' is the number of modules then for each module we count 1/n * percent_of_module. This is fair enough so nobody complains and yet it can be enhanced to give higher weight to more important modules (where such a definition can be agreed upon).
- Using the above formula:
- Hebrew changes from 72% to 79%
- Arabic changes from 98% to 96.8%
- Dutch changes from 90% to 92%
- French keeps on 99%
- Catalan keeps on 97%
- Irish from 29% to 31%
- Japanese keeps on 95%
- Swedish keeps on 99%
- Russian changes from 93% to 90%
- Greek changes from 84% to 83%
- Norwegian changes from 64% to 65%
- Croatian changes from 45% to 37%
- Welsh changes from 72% to 63%
- Latvian changes from 78% to 73%
- Indonesian changes from 70% to 65%
- Albanian changes from 73% to 72%
- Georgian changes from 52% to 57%
- And so on...
- Regarding the Development tools: Using my suggestion they would count for 6.5% where as they count for 7.7% today. This is not best. Ideally we should also give different weight for different topics. For example: 10% developers platform, 80% desktop, 3% administration tools and 7% developers tools. Of course this is an arbitrary partition.
- This way a team can choose not to translate a certain section (due to priorities), for example the development tools, but it should keep in mind that it won't be able more than xx% (for example 7%) of the gnome desktop.
References
Comments
I think extending gradual completion is best thing to do here. We can have something like "Gold", "Silver" etc. languages for GNOME regarding their translation ratio. That would motivate the language teams in order to state their languages in upper league. Release notes can have a direct link of this grading on l10n.gnome.org web page. Even though it might be a little harsh to include massive modules, it would really harm the communities which have enough resource but wanting to up the bar. There should be a grading for documentation and even for extras modules. (BarisCicek)