On 11/6/12 12:23 PM, jan iversen wrote: > 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.
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. 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 >> >
