Return-Path: X-Original-To: apmail-openoffice-dev-archive@www.apache.org Delivered-To: apmail-openoffice-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 270D5D61A for ; Tue, 6 Nov 2012 11:24:04 +0000 (UTC) Received: (qmail 46746 invoked by uid 500); 6 Nov 2012 11:24:04 -0000 Delivered-To: apmail-openoffice-dev-archive@openoffice.apache.org Received: (qmail 46551 invoked by uid 500); 6 Nov 2012 11:24:04 -0000 Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openoffice.apache.org Delivered-To: mailing list dev@openoffice.apache.org Received: (qmail 46528 invoked by uid 99); 6 Nov 2012 11:24:03 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Nov 2012 11:24:03 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jancasacondor@gmail.com designates 74.125.82.174 as permitted sender) Received: from [74.125.82.174] (HELO mail-we0-f174.google.com) (74.125.82.174) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Nov 2012 11:23:56 +0000 Received: by mail-we0-f174.google.com with SMTP id t9so157115wey.33 for ; Tue, 06 Nov 2012 03:23:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=r6iENHGaawi9rMov14vmn8Vk7ocz8wfEllpoXy0lKiY=; b=f0+NRHVHnoE33gwXKRrxkyuewi9Bhhl/DsphLmMb9Wngc5UpJTSMCGbIx55BAZsiT2 bbjn+FtFjNBZXmpeaq/ErfJeUENMTYMN2BGvM4YKnv3+ui7BJNhqu7svu1R6SVpWqD0G D2Do2WgJqmSLjiRHTHOWnKCNicXaXuDMEo+ym+kqLBaGsDezyCzgD/Dkhlpb1A6Fkb+7 2XS99uTG6jf0vS9trqswj2F7hJCjUZWkdJiBsiJDe8eDt1hphr4j7CbUlKh6Z1Tv/B1/ WyM6jZXC10cNOSeOTJTjOLKXo2k70KRllb4C563KgSDhYioLQMsrKWgPIFp3/HCmF88p /nig== MIME-Version: 1.0 Received: by 10.180.92.103 with SMTP id cl7mr1382449wib.16.1352201016041; Tue, 06 Nov 2012 03:23:36 -0800 (PST) Received: by 10.217.68.194 with HTTP; Tue, 6 Nov 2012 03:23:36 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Nov 2012 12:23:36 +0100 Message-ID: Subject: Re: [early codereview / check for standards] genLang in l10ntools From: jan iversen To: dev@openoffice.apache.org Content-Type: multipart/alternative; boundary=f46d04388e4939e03a04cdd1d514 X-Virus-Checked: Checked by ClamAV on apache.org --f46d04388e4939e03a04cdd1d514 Content-Type: text/plain; charset=ISO-8859-1 On 6 November 2012 11:58, Dwayne Bailey wrote: > On 6 November 2012 10:25, jan iversen wrote: > > > I prefer .xlif because it is easier to handle, and I do not need to store > > information (like module/source file) in comments. > > > > You still need to store some reference right? > Yes, we intent to generate 1 file pr module, instead of as today 1 file pr 1 source file. Thereby I loose the relationship which need to be stored in the file itself. This will reduce the number of files to 2x48 (one set UI, one set HELP), and make it easier for translators. > > I think preference in some way should be decided by what people are doing > in terms of translation. Pootle can handle both XLIFF and PO. But there > might be quite a few people who translate offline using PO tools. This > would mean for many a tool change. But I'm not sure how many people are > translating offline. > According to andrea most people work offline, and then do statistics and fine tuning with pootle. It was be a smashing hit to have a pootle client (based on viraal), so people could work offline and online using the same gui !!! I agree it might not be easy to get people to change tool, however I might have found a variant, we store all internally (incl. pootle server) in XLIFF and when downloading from the pootle server there could be a choice of format. When uploading a PO file, it is quite simple to match the linenumbers. > > > > > > However the issue is still open, and I think andrea/juergen will have a > > talk with you on that subject, and a couple of pootle server details > during > > this week. > > > > thanks for correct .xliff to .xlif, automatic spelling control has one > > disadvantage, spell it incorrect once and it is always incorrect (that is > > called being consistent). > > > > .xlf :) > Never write anything too fast, it catches up with you, thanks for correcting it. > > I thought I had cleaned the source for this issue, so I will just rewrite > > that note. What I do development wise, it to convert it all into a > > translation memory, and then have a separate output class, that way the > > issue is not very sensitive and can be easily changed. > > > > Can you maybe explain that further, I'm not a fan of TM that decides > e.g.Open == Open in the source when it is translators who need to make that > decision. How are you disambiguating those cases. > > It is just my development. The structure of the classes are (roughly): -- handler, controls what needs to be done (extract, merge....) and handles the logistic. -- converter (read source files and generates internal language tree or read language tree and generate source files) -- output (read language tree and write language files, or read language files and generate tree) there will not be a choice in the actual code, but I need only program the file format once (and not as today in 7 modules). When I come to that point I need a decision what to program, but if we later make a new decision I can easily change it, without needed to go into the other parts. I am with you, it is not something the translator should decide, especially since they are part of a bigger workflow. > > > > Have a nice day > > Jan. > > > > On 6 November 2012 10:54, Dwayne Bailey wrote: > > > > > On 4 November 2012 12:55, jan iversen wrote: > > > > > > > Hi. > > > > > > > > I have finished the control part of the new localization tool, and > > before > > > > I walk further down the line (writing/converting all the translations > > > > parts) I would like to have checked if the code is ok in terms of > > > standard, > > > > readability and expectations (from other C++ programmers). > > > > > > > > I hope one of the C++ programmers, can have a quick look at the code > > and > > > > tell me: > > > > - Are the code written in accordance with the AOO standards (I think > > so) > > > > - Is it in general in accordance with the AOO writing style. > > > > > > > > Of course, I would very much like to hear if there are non-efficient > / > > > > malicious code in there, but please remember this is only the control > > > > skeleton, so there are a lot of code missing. > > > > > > > > > > Hi Jan, I just wanted to check what the target format was. It looks > like > > > XLIFF from the example in one header, is that correct? Or are you still > > > wanting to target PO? There are pro's and con's to each. PS the XLIFF > > > extension is .xlf not .xliff. > > > > > > > > > > > > > > I try to include a zip file with this mail, should I not succeed, > then > > > > please respond to the mail and I will sent it directly. > > > > > > > > MANY Thanks in advance for the help. > > > > Jan. > > > > > > > > > > > > > > > > > > > > -- > > > Dwayne > > > > > > *Translate* > > > +27 12 460 1095 > > > > > > > > > -- > Dwayne > > *Translate* > +27 12 460 1095 > --f46d04388e4939e03a04cdd1d514--