Thanks a lot for your long and informative answer, I read it with a positive attitude and will just make one comment, it is hard to be new especially with the state of documentation we have. I will in the future make a lot less noise.
I will work your comments into my proposal, and in general I agree it is better to extend existing tools than to make new ones. There is however one misunderstanding (probably due to my formulations) that I need to correct, the l10n upload/download feature was NOT to circumvent the system, but to allow contributors to upload files without having to go through private mail adresses/bugzilla etc. Thanks for using time on my proposal. Jan. On 25 October 2012 23:01, Andrea Pescetti <pesce...@apache.org> wrote: > On 21/10/2012 jan iversen wrote: > >> I have finally finished my proposal for a new workflow. >> please have a look at: >> http://wiki.openoffice.org/**wiki/File:L10procNew.pdf<http://wiki.openoffice.org/wiki/File:L10procNew.pdf> >> > > It seems I'm the first one who replies after having read your document in > full. And the quality of your proposal is not the issue here: on the > contrary, it is a very good one and I'm answering in detail below. So the > issue must be somewhere else. I'm confident you will understand that I'm > not criticizing or lecturing you here, and I'm not implying any of the > items below to be you fault (none is); but maybe this will help you in > getting better feedback in future. > > 1) Unfortunate timing. We've just graduated, the Apache Conference is > coming in about one week, we need to relocate all infrastructure... It's a > busy period, so we may be less responsive than usual. > > 2) Excess of communication. If all people on this list had written as much > as you did in the last 24 hours to the OpenOffice lists, ooo-dev would have > received a message every 9 seconds! If you make yourself manageable it will > be easier for us to answer your requests with less confusion. > > 3) Dispersion of communication. Discussion about your proposal is > scattered in three different threads across ooo-dev and ooo-l10n (not > counting private e-mails); if you need to send a message to multiple lists, > and this is a good example, it's best to send one message to two lists (and > specify which one should receive answers) since answers will be grouped in > the same discussion for people who are reading e-mail by discussions. > > 4) Proposal format. Uploading a PDF is very convenient but it does not > make others feel empowered to really contribute. I would have applied a > dozen typo fixes to your proposal if it had been available as a wiki page. > Others might have done the same. > > OK, enough said. The proposal has significant merit, so let's focus on > that for the rest of this message. It won't be short: it's still a 20-page > document. > > The main reasons to drive it forward are: > - It puts us back in total control of the l10n process, with no need to > rely on partially broken or lost tools. > - It reduces the number of steps strings must go through for being > translated and imported back. > - It automates a number of operations that have been manual so far. > - It allows to have a proper version control for translations. > > In general, I think the document would benefit from some knowledge about > how the process works with established teams: > - There is a "string freeze" date in the release schedule (this concept > needn't be taken away: for sure we still want a string freeze even if tools > allow a continuous localization; translators shouldn't have the surprise to > see new strings appear in the last weeks before a release) > - After string freeze, strings are made available in Pootle (and this > happens automatically in your proposal) > - Volunteers pick a file, usually a help file and the main application > related to it (so, the "sw" module for Writer and its help file; and, > answering another message from you, the subdivision you propose would be > OK). Here indeed it is helpful to know that a file has been taken, > something that volunteers track manually at the moment. Volunteers do not > have time constraints and may well take two weeks to complete their > assignments: the "4 days" you propose are not realistic for most teams. > - Nobody works on Pootle. This has nothing to do with rights, it is > totally incorrect to see Pootle as the "committers tool". The Pootle server > used to be slow and not responsive and anyway, as a matter of fact, most > people, including me, prefer to work with downloaded files. > - Volunteers mark all strings they touched as "fuzzy" to distinguish them; > if I understand correctly, a XLIFF based workflow here would suggest to > mark the strings as "to be reviewed". > - Other volunteers (in general one person per language) review the > translations, collect all files and make them available to developers > (Bugzilla, personal web space, e-mail...) > > So we already have a (kind of) "team coordinator" who reviews the files > and is a committer. Again: you can assume that we have a person per > language who is a committer (new languages go through a brief transition > phase, but as you probably understood from the 20-30 daily answers you > receive from committers, we try to be rather active in mentoring and > helping in this transition phase). > > Now I don't see the need for the web application you propose for > l10n.openoffice.org. It seems a way to circumvent the policy in order to > allow non-committers to do something that committers can do: but if the > policy is problematic, we'd rather discuss and change it than building > tools to circumvent it. And, under the assumption that for each language we > have a reviewer/committer, I would just use the Pootle functions for that. > Pootle already offers: download, upload, visual representation of > translation progress, integration with version control (but this might be > simpler than what's required here). In short, instead of building new > tools, I would investigate what's needed to configure/enhance Pootle to > implement the workflow you envision, assuming we have a reviewer/committer > for each language. > > A tool that, instead, would be extremely useful to our translators would > be something where they can see the context of the string they are > translating. I didn't see it in your document, but every string has a > "KeyID" that makes it possible to identify it uniquely, and you can build > OpenOffice making a "kid build" (possibly --with-lang=kid ?) which will add > the key to every string. If we had a way, any way, where translators could > see a screenshot showing their string in context (i.e., the "Next" I'm > translating now is string KeyID "abc123" and thus the string "Next-abc123" > displayed in this screenshot taken in the kid build) this would help them > immensely. For the record, we removed Testtool from the sources recently > but it allowed taking automated screenshots, and could maybe have been > helpful here. > > The rest is fine, definitely. > > I'm only a bit reluctant on the idea that building OpenOffice (page 13) > may result (if I get it right) in resources to be committed again. First, > we don't want to depend on version control (I mean: the build can well be > made on a "svn export", or an anonymous checkout, or two developers can > build simultaneously); second, committing something from a partial build is > probably best avoided; third, our snapshots are usually based on a specific > revision or tag, so building them shouldn't create a new revision. I > understand that the build will of course work even if the language files > are not committed, but maybe there is some other way to enforce consistency > between code and language files (or we just agree that we will enforce it > just before tagging). > > For PO vs XLIFF, it would help to have a list of tools listed in each > paragraph, but this is a tangential issue so far. > > Regards, > Andrea. >
