You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by janI <ja...@apache.org> on 2013/05/31 12:34:24 UTC
glosary/terminology files in pootle
Hi.
I have been hesitating to write this mail, due to the publicly announcement
that I am "opposing the project", but the work of Claudio Filho deserve
merit and action.
Claudio Filho mailed me a terminology/glosary which are well suited for our
pootle server.
We can use terminology in pootle, not only as a online dictionary (which
does not work well) and/or as part of the review process which would be
more efficient.
It seems to me that we are not planning to use pootle review function (or
any other function) for reviewing the translations.
My suggestion is clear: add terminology, and request the reveiw function to
be used (meaning that a language need to have passed the review, and
warnings have been controlled, in order to be released).
I will not make this change unless there are 100% backing from the
community.
thx cladio for your work, and bringing this to the attention of the
community.
rgds
jan I.
Re: glosary/terminology files in pootle
Posted by janI <ja...@apache.org>.
On 3 June 2013 22:47, Claudio Filho <fi...@gmail.com> wrote:
> Hi
>
> 2013/6/2 janI <ja...@apache.org>:
> > On 2 June 2013 15:37, Andrea Pescetti <pe...@apache.org> 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: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: glosary/terminology files in pootle
Posted by Claudio Filho <fi...@gmail.com>.
Hi
2013/6/2 janI <ja...@apache.org>:
> On 2 June 2013 15:37, Andrea Pescetti <pe...@apache.org> 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.
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.
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.
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.
About the Pootle, i can help in admin it, if necessary (backup admin?). ;-)
Cheer
Claudio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: glosary/terminology files in pootle
Posted by janI <ja...@apache.org>.
On 2 June 2013 15:37, Andrea Pescetti <pe...@apache.org> wrote:
> On 31/05/2013 Jürgen Schmidt wrote:
>
>> On 5/31/13 12:34 PM, janI wrote:
>>
>>> My suggestion is clear: add terminology, and request the reveiw function
>>> to
>>> be used (meaning that a language need to have passed the review, and
>>> warnings have been controlled, in order to be released).
>>>
>> A good idea and we should indeed work towards such a review process. I
>> learned today how difficult it can be to translate some specific things.
>>
>
> 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.
rgds
jan I.
> Regards,
> Andrea.
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: glosary/terminology files in pootle
Posted by Andrea Pescetti <pe...@apache.org>.
On 31/05/2013 Jürgen Schmidt wrote:
> On 5/31/13 12:34 PM, janI wrote:
>> My suggestion is clear: add terminology, and request the reveiw function to
>> be used (meaning that a language need to have passed the review, and
>> warnings have been controlled, in order to be released).
> A good idea and we should indeed work towards such a review process. I
> learned today how difficult it can be to translate some specific things.
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?
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: glosary/terminology files in pootle
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 5/31/13 12:34 PM, janI wrote:
> Hi.
>
> I have been hesitating to write this mail, due to the publicly announcement
> that I am "opposing the project", but the work of Claudio Filho deserve
> merit and action.
come on, you know exactly that this is not true and we appreciate all
what you are doing.
>
> Claudio Filho mailed me a terminology/glosary which are well suited for our
> pootle server.
>
> We can use terminology in pootle, not only as a online dictionary (which
> does not work well) and/or as part of the review process which would be
> more efficient.
>
> It seems to me that we are not planning to use pootle review function (or
> any other function) for reviewing the translations.
well I would say it's simply because the lack of knowledge. We can
benefit from anybody who is familiar with translation and/or Pootle and
can show us how we can improve our process or can benefit from new
features of Pootle.
I volunteered to manage some basic stuff regarding the po files and
updating the translation sources etc. but I am no expert here ;-) I
simply volunteered because there was nobody else.
I would be happy if we would have more people who had motivation, the
knowledge to support me and of course who are interested to earn the
karma from infra to work on the Pootle server ;-)
>
> My suggestion is clear: add terminology, and request the reveiw function to
> be used (meaning that a language need to have passed the review, and
> warnings have been controlled, in order to be released).
A good idea and we should indeed work towards such a review process. I
learned today how difficult it can be to translate some specific things.
>
> I will not make this change unless there are 100% backing from the
> community.
We can enable this feature and can build some knowledge and experience
how to use it efficiently. When we have a much better picture how to use
it we can make it a requirement in the future. In general I would
support this to ensure the quality. But it make most sense if we have
more than one volunteer for a language ;-)
>
> thx cladio for your work, and bringing this to the attention of the
> community.
+1
Juergen
>
> rgds
> jan I.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org