On 6 November 2012 11:58, Dwayne Bailey <dwa...@translate.org.za> wrote:
> On 6 November 2012 10:25, jan iversen <jancasacon...@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. 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 <dwa...@translate.org.za> wrote: > > > > > On 4 November 2012 12:55, jan iversen <jancasacon...@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 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 >
