On 3 June 2013 22:47, Claudio Filho <[email protected]> wrote: > Hi > > 2013/6/2 janI <[email protected]>: > > On 2 June 2013 15:37, Andrea Pescetti <[email protected]> wrote: > >> Adding terminology seems fine, of course. Requiring the review step is > in > >> principle OK for me too, but I wonder how it will work for languages > where > >> we don't have native speakers as committers: does it require that > strings > >> are explicitly marked as reviewed, or is it enough to ask volunteers to > >> check the warnings generated by Pootle and then send a note to the l10n > >> list saying that they have considered/ignored warnings appropriately? > >> > > > > Asking volunteers to that would be a significant step in getting better > > quality. > > > > The nice thing about pootle review is that it can be done be everyone. My > > idea was to say something like "before moving po files back to svn, the > > committer must run a pootle review, if there are errors/warnings not > > explained by the translators on the mailing list, the files will not be > > transferred". I know it puts a little burden on the person who does the > > transfer, but similar to receiving a code patch. > > I think that we have some mistake about the "review". >
One thing is to generate all strings in the source lang, like en_US. > When you do it, you can give any inconsistent problems, like use > differents terms in differents parts doing the same thing. IMHO, the > translation team from Sun did a incredible work about this interchange > about UI and help contents. > This is a very important part, but not something we can have a program doing, I think the only way is having people look at a running AOO. > Other step is to translate it for many langs, like StarOffice/OOo/AOO. > A good practice is the use of glossary/terminology, giving to team a > way to translate in the same way. Is possible to do this work without > the glossary/terminology, but is possible that you will have a UI/help > with differents terms for SAME thing, or some thing worse, like > differents parts of UI with differents strings for the SAME thing. > That was what I thought of. Providing a glossary is the first step (this can be generated based on existing translations), having a glossary also allows us to: 1) ask the translators to use pootle review 2) Check/enforce that the glossary is used, this can be done quite easy by e.g. genLang. 3) Auto translate new strings (with fuzzy bit on), if in the glossary > IMO, we are in this edge between the good and acceptable, and now, we > can start a revision of all work. An example: pivot table, in pt_BR, > was translated for "Assistente de dados" (data wizard?) instead > "Tabela dinâmica". Before, all strings was consistent with the first > option, that is good, but isn't the good choice of term. Today, (i > believe that) all UI/help are aligned with the second term, that is > more appropriate. > > When i did the translation, i found some original strings that could > be written in other way or using other example. So, you can see 2 > review to do: one for original strings and other for evolve the > translations. > agreed. > > In this time, if we implement the terminology practice, the new > translations can do first the translation of glossary, and after load > in pootle and provide for them translators the po file (to offline > translations), giving a tool for a better and consistent translation. > Who already did his translation, can review the work, giving a better > quality for his translated AOO through revising the glossary and > reflecting this work in the UI/help. Is possible too ignore this > practice and do it freely. :-) > > Anyway, i think/suggest to start the process revision after 4.0[.1?]. > Today, only provide the resource and the use is free to all teams. > Yes, as soon as 4.0 is released, I intent to update genLang and get it integrated. > > About the Pootle, i can help in admin it, if necessary (backup admin?). ;-) > thx for the offer. Pootle and the vm as such is being adminstrated by infra, but in my opinion an extra project admin would be nice @jsc as project admin, what is you view ? rgds jan I > > Cheer > Claudio > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
