Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openoffice.apache.org
MIME-Version: 1.0
In-Reply-To: <50B4ABC8.6070908@gmail.com>
References: 
 <CAK2iWdRWQYCtbb3vDtwGh4Sk3KocB2ee9QizLiGdAw_qSoxizw@mail.gmail.com>
	<CACbjkN6MnrgzTNz1=tFffeuUWsxWSARO42BwHHBw=6Y3KL4ONQ@mail.gmail.com>
	<CAK2iWdQqXpUH4nJkNw5N0o-vPG6i8QeUyZif4Lnov0_3O_dgWg@mail.gmail.com>
	<CACbjkN7pnX=aGrhfTByMsWyAboGjt7D6pY7h91vnf1WLGqT0fg@mail.gmail.com>
	<CAK2iWdS2g=U6fvOygvNK8+QgHn5UHXRe=G1k6796-AL0i-7w9g@mail.gmail.com>
	<50B4ABC8.6070908@gmail.com>
Date: Tue, 27 Nov 2012 14:20:09 +0100
Message-ID: 
 <CAK2iWdRdRBij5SML8bTe6xaGCdx9Q5Rc7OYzrqZBLcDg7ffRxQ@mail.gmail.com>
Subject: Re: [early codereview / check for standards] genLang in l10ntools
From: janI <jani@apache.org>
To: dev@openoffice.apache.org
Content-Type: multipart/alternative; boundary=e0cb4efe2b2ac035ce04cf79e892

--e0cb4efe2b2ac035ce04cf79e892
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

We do not generate it at main level, like we want to, we generate at a
lower level today.

if you look in the .po files, you will see the filereferences are inserted
as comments, and there are no rules saying that an editor shall keep the
comments in exact the same place. If just one comments moved (or the
msgText moved, but the comment stays, which happened in one of the danish
files) then it cannot be sent back to the source tree. As .po files grow
larger, this problem becomes much more violent.

But I have understood that the community wants to stay with .po files, so
that is what will be developed.

Jan I.

On 27 November 2012 13:02, J=FCrgen Schmidt <jogischmidt@gmail.com> wrote:

> On 11/6/12 12:23 PM, jan iversen wrote:
> > On 6 November 2012 11:58, Dwayne Bailey <dwayne@translate.org.za> wrote=
:
> >
> >> On 6 November 2012 10:25, jan iversen <jancasacondor@gmail.com> 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.
>
> today we generate 1 po file for 1 directory where multiple resource
> files are, means no direct 1:1 relation ;-)
>
> Juergen
>
> 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.  Thi=
s
> >> would mean for many a tool change.  But I'm not sure how many people a=
re
> >> translating offline.
> >>
> >
> > According to andrea most people work offline, and then do statistics an=
d
> > fine tuning with pootle. It was be a smashing hit to have a pootle clie=
nt
> > (based on viraal), so people could work offline and online using the sa=
me
> > 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 choi=
ce
> > 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 on=
e
> >>> disadvantage, spell it incorrect once and it is always incorrect (tha=
t
> 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 t=
he
> >>> 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 =3D=3D 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 languag=
e
> > 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 <dwayne@translate.org.za>
> wrote:
> >>>
> >>>> On 4 November 2012 12:55, jan iversen <jancasacondor@gmail.com>
> 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 translatio=
ns
> >>>>> 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 cod=
e
> >>> and
> >>>>> tell me:
> >>>>> - Are the code written in accordance with the AOO standards (I thin=
k
> >>> 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-efficien=
t
> >> /
> >>>>> malicious code in there, but please remember this is only the contr=
ol
> >>>>> 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 XLIF=
F
> >>>> 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
> >>
> >
>
>

--e0cb4efe2b2ac035ce04cf79e892--