On Sun, Jul 14, 2013 at 12:37 PM, Marcus (OOo) <[email protected]> wrote: > I tie up to Kay's suggestion to discuss a new policy. So, new topic, new > thread. > > For reference here is the old policy: > http://wiki.openoffice.org/wiki/Release_criteria#Localization_requirements > > My new suggestion: > > 1. Don't make a difference between UI and Help. > > 2. Accepted translations that are 90% or better. > > 3. *Except* we have a big or strategic new feature like the Sidebar. This > should be translated much better than 90%. > > Why? > > 1. Do we want to make differences between UI and help translation? Do > average users accept English help topics for translated UI functions? I > don't think so. > > 2. In the previous OOo project translations were accepted with 80% or better > for a release. IMHO this is too low to offer a high quality release. > > 3. New features that are also promoted in release note, blog post, etc. > should be fully translated as the attention of our users is high here. They > want to give it a try and shouldn't be disappointed with not translated > parts. > > And now, add your points. >
I'd prefer to keep the current rule, 100% UI translation. But I'd be open to requiring 100% for help as well. IMHO we should be raising the bar, not lowering it. If there is a community willing and able to translate to 90% then there should be community willing and able to translate to 100%. There is no technical or community reason to stop at 90%. It is only a question of time. I'd prefer we just wait for 100% translation and then release it. On the other hand, if a language is stuck at 90% and there are no active volunteers, then I don't think we should release it. If it will not get to 100%, then we're just release something that will reflect poorly on us and will slowly degenerate from release to release. In other words, if it is merely a case of waiting another month or two and then releasing a high-quality 100% translation, then I think that is better than releasing something only partially done. Also, there is the "slippery slope" here. If we allow 90% complete then someone will beg for 89% complete, or 88% complete. What I would favor is making builds available, maybe at the level of AOO 4.0, in all languages that are "close", maybe 80% or 90%. Not for release or distribution, but to help volunteers evaluate its current state and help translate. Regards, -Rob > Marcus > > > > Am 07/14/2013 05:43 PM, schrieb Kay Schenk: >> >> On Sun, Jul 14, 2013 at 8:13 AM, Rob Weir<[email protected]> wrote: >> >>> On Sun, Jul 14, 2013 at 3:42 AM, Juergen Schmidt<[email protected]> >>> wrote: >>>> >>>> Am Sonntag, 14. Juli 2013 um 06:35 schrieb imacat: >>>>> >>>>> On 2013/07/13 20:52, Ariel Constenla-Haile said: >>>>>> >>>>>> On Sat, Jul 13, 2013 at 12:20:32PM +0200, Marcus (OOo) wrote: >>>>>>> >>>>>>> Am 07/13/2013 05:14 AM, schrieb Ariel Constenla-Haile: >>>>>>>> >>>>>>>> On Fri, Jul 12, 2013 at 11:54 PM, imacat< >>> >>> [email protected]> wrote: >>>>>>>>> >>>>>>>>> Sorry. I did not see Traditional Chinese version. Did I missed >>>>>>>>> something on the Traditional Chinese version? >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> UI translation is not complete: >>> >>> https://translate.apache.org/zh_TW/aoo40/ >>>>>>> >>>>>>> >>>>>>> I can see that 97% is translated. Not that bad. Do we have an >>>>>>> agreement that we need 100% for a release? >>>>>>> >>>>>> >>>>>> >>>>>> http://markmail.org/message/pxgvjuw2j3ukqsom >>>>>> >>>>>> Concerns should have been risen at that time, it was discussed on the >>>>>> mailing list, and properly tagged ("if it does not happen on the >>> >>> mailing >>>>>> >>>>>> list..."). >>>>>> >>>>>> >>>>>>> I'm asking because I really don't know it and in former OOo times we >>>>>>> have done releases for languages with at least 80% translated UI >>>>>>> [1]. So, maybe a change that I haven't seen in the last weeks. >>>>>>> >>>>>> >>>>>> >>>>>> For this particular case, the translation of the main 4.0.0 feature is >>>>>> incomplete >>> >>> https://translate.apache.org/zh_TW/aoo40/svx/source/sidebar/ >>>>>> >>>>>> How serious would it be to release this translation in such a state? >>> >>> The >>>>>> >>>>>> same applies to other languages released in 3.4.* but not in this >>> >>> 4.0.0 >>>>>> >>>>>> RC. >>>>>> >>>>> >>>>> >>>>> Hmm... I see the problem with side bar translation. And I'm very >>>>> sorry that I was in my research paper and did not notice the previous >>>>> discussion. However, there are several issues of concern: >>>>> >>>>> 1. I am going to give a talk in our largest local open source >>>>> conference (COSCUP 2013, http://coscup.org/) on 8/3, and plan to >>>>> announce OpenOffice 4.0. It is the first talk after the key notes. It >>>>> would be very embarrassing to announce it without a local version >>> >>> released. >>>>> >>>>> >>>>> 2. There would be a large-scale deployment around August or September >>>>> (6000-7000) in a government department, and they are planning to join >>>>> our development force in order to fix some Chinese problems in >>>>> governmental use. If OpenOffice 4.0 Traditional Chinese version is not >>>>> available at that time, we could only give them 3.4.1, which their >>>>> development could not be based on. >>>>> >>>>> I've asked our local community to help the translation in urgent. >>>>> If we can finish the Traditional Chinese sidebar translation with >>>>> certain amount, could it be OK to release it? >>>>> >>>> let translate the UI First and then we can figure out what's possible. >>> >>> Hopefully some other languages can continue the translation as well and >>> we >>> can think about a language only release where I am a big fan of to >>> support >>> local communities. >>>> >>>> >>> >>> There is obviously some tension in our goals here: >>> >>> 1) We want to release the good work that is already done, so users who >>> can enjoy the new features, bug fixes, interop improvements, etc. >>> >>> 2) We also have some languages that are "almost" done and don't want >>> to "miss the train". >>> >>> IMHO the way to resolve this tension is to let the current 4.0 train >>> leave the station, but announce another train is leaving soon. Maybe >>> we can set a goal of September 16th for either a 4.0.1 (if we're >>> making code changes for a new critical bug) or a language update of >>> 4.0.0 (if there are only new translations). Hopefully we all remember >>> that we did this with AOO 3.4.1 as well, adding more languages after >>> we released. >>> >>> From what I can tell there is a steady stream of interest in >>> translating AOO to other languages. There will always be another >>> language that is "almost ready". That is what success looks like. We >>> need to handle new translations when they are ready. We can't hold up >>> the train, but we also can't make volunteers wait too long for the >>> next train. >>> >>> So how does September 16th sound for releasing additional languages? >>> Is that enough time? >>> >>> -Rob >>> >> >> This seems quite reasonable to me. We need a little time for regrouping, >> and dealing with perhaps some minor issues that might pop up from the 4.0 >> release. >> >> Re the old stated "policy" on : >> >> http://wiki.openoffice.org/wiki/Release_criteria#Localization_requirements >> >> If this no longer our policy, we should definitely change this. >> >> But...I think we should first discuss the policy. What levels of >> translation do we feel are acceptable if not at 100%. What do we >> absolutely >> require to be translated? Menus vs help files, for example. >> >> Once we determine translation thresholds, we should include the policy on >> the "Native Language" page on the project web site: >> >> http://openoffice.apache.org/native-lang.html >> >> >> >>> >>>> But in general we have discussed it and I would have not released German >>> >>> (my mother language) if the UI translation would have been not complete. >>>> >>>> Just to make sure that we need active local communities who participate >>> >>> in the project or at least in the translation part. >>>> >>>> >>>> It would be even better if the help would be translated as well but that >>> >>> is a much higher burden and we are more flexible here. >>>> >>>> >>>> Juergen > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
