Il 29/04/2014 09:47, jan i wrote:
On 29 April 2014 09:36, Jürgen Schmidt wrote:
we had something like this before but defined a new rule to be 100% UI
complete and I think this is quite easy and a good rule.
Note: I'm keeping the 100% rule to add a language. I'm just saying that
we shouldn't drop languages for 4.2 if they are 100% complete in 4.1, to
match users expectations. I definitely don't want to see more complex
combinations of factors, just think like a user.
The case Andrea described above should be more theoretical if an active
community is behind a translation.
Theoretical? It is very concrete. We already dropped (and then rescued)
Norwegian, Danish and others due to missing coordination: we did have
active volunteers, but they missed a deadline and we didn't include it.
I can find it acceptable for a major release, but not for the minor
versions (4.0, 4.1, 4.2...).
Note: if the late README change to correct the minimal OS X version had
been imported into Pootle correctly, we would have had all languages at
99.99% just before RC time... and that would have been interesting!
I would still prefer the 100% rule. But anyway it's my personal opinion.
+1, not requiring 100% UI (which is quite easy to do for any translator) is
a dangerous path.
Who is this dangerous to? Intermittent support is very bad for users and
it hurts our reputation more than a missing minimal translation update.
For minor updates I would focus in converting users into volunteers: the
new JavaScript magic on the download page could display a "Help needed"
warning when someone downloads a currently unmaintained language (which
will still have very high coverage, since we only add a language when it
reaches 100%).
And for major updates (here I mean 5.x, assuming that major UI changes
are accompanied by major localization changes) we would start clean and
require 100% again.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org