On 4/30/14 12:28 AM, Marcus (OOo) wrote: > Am 04/29/2014 07:57 PM, schrieb Rob Weir: >> On Tue, Apr 29, 2014 at 1:47 PM, Marcus (OOo)<marcus.m...@wtnet.de> >> wrote: >>> Am 04/29/2014 09:47 AM, schrieb jan i: >>> >>>> On 29 April 2014 09:36, Jürgen Schmidt<jogischm...@gmail.com> wrote: >>>> >>>>> On 4/29/14 9:20 AM, Tal Daniel wrote: >>>>>> >>>>>> On Tue, Apr 29, Andrea Pescetti wrote: >>>>>> >>>>>>> I propose that, once a language reaches our release quality criteria >>>>>>> (currently: UI translation at 100% and maintained), we do not >>>>>>> drop it >>>>>>> afterwards for the other minor releases. >>>>>>> >>>>>>> [...] I would remove unmaintained languages only when version 5.0 >>>>>>> comes. >>>>>>> >>>>>> >>>>>> Seems reasonable, to me, Andrea, I'm not sure that removing a >>>>>> language >>>>>> on >>>>>> major release should be so strict. What about removing a language >>>>>> only >>>>> >>>>> when >>>>>> >>>>>> a MINIMUM% of it isn't translated (e.g., 10%)? >>>>>> >>>>> >>>>> 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. >>>>> >>>>> The case Andrea described above should be more theoretical if an >>>>> active >>>>> community is behind a translation. We released Arabic with 3.4 but >>>>> there >>>>> was no active community and nothing happened later on. >>>>> >>>>> 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. >>>> >>>> Nobody can today say when we do the next major release (5.x) meaning >>>> translations< 100% could be ongoing for a long period. For a minor >>>> release, its typically only a handful of messages that are changed, >>>> so it >>>> not a big workload for any individual. >>> >>> >>> However, from the view point of a normal user who just wants to >>> update to >>> the next version, it would be confusing why no localized install file is >>> available anymore. >>> >>> So, from my side a clear +1 to keep these languages. >>> >>> How much we allow to be under 100% is just a question of definition (and >>> agreement). ;-) >>> >> >> We want quality releases. % translation is part of quality, of >> course. But there are other aspects as well. Certainly looking at % >> completeness is easy for to measure, but it is not necessarily the >> best criterion. >> >> We want to avoid a situation where a translation is rushed and done >> poorly, in order to meet an arbitrary % goal. I'd rather have a high >> quality 95% than a low quality 100%. > > You should have replied to my other mail. ;-) It seems we have the same > direction of the vision. > >> Of course, PMC members do not know all languages. So we need to rely >> on the translators and the local community. Maybe we can make a >> criterion from that? >> >> For example: >> >> If a translation is more than X% complete, AND if that language was >> downloaded in the beta release more than Y times, AND the RC was >> reviewed by the translator and Z other community members to vouch for >> having usable level of quality, then we include it in a release. > > Yes, sounds good. > >> Or some other way of having the local community take ownership of >> making this decision. > > What about to include another AND: > > AND ZZ the language has recent activity on Pootle. > > Even when the language is a bit far away from 100%, with activity on > Pootle we can be sure (somehow) that the language is maintained.
we should first streamline the process and have a better integration process in place. Currently I am doing all then work but I am not interested in doing more. I will continue to integrate new languages and merge language back from time to time but better would be if genlang can be finished (and I am sure Jan needs help here and volunteers are welcome) or somebody else steps up to support me ;-) Juergen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
