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/09/06 14:30:17 UTC

Question to all developers and translators: How integrated should translation be ?

Hi

I am copying this mail to the l10n list, in order to involve the
translators that do not follow dev@. But lets please keep the discussion on
dev@.

As its hopefully known, I have been working on a new workflow for the whole
translation process for quite a long time.

Now I have released the first major part of the workflow, my ultimate
commit has lead to some valid concerns from Jürgen and Herbert, this is the
second time (during development) that I hear the essentially same concern.

Therefore we a a community need to decide which road we want to follow.

The workflow I am developing, would in the final phase look like (without
technical details).

1) at regular intervals en-US text are extracted from our source tree,
transferred to pootle as templates, and all languages are updates with
new/changed/deleted keys. This part is partly manual (starting the build,
updating the languages).

2) Translators work on pootle, Translator-comitters update languages in svn
from pootle and start an offline language-pack build.

3) Translators test their translation using the binary from our buildbot  +
language pack (translators debug tool). Turnaround time < 1 day.

4) Buildbot automatically include changed translations on regular builds
(e.g. weekly).

The 2 concerns that have been raised are:
1) Letting committers do "svn commit" and "svn up" directly in pootle,
might produce a build breaker for our buildbots. Suggestion let an admin do
it e.g. once a week.

my opinion: We do not need an admin in the loop, we dont have a controlling
for developers and they are even more likely to produce build breakers.
Remember a .po file build breaker will only affect the language in question
and can be repaired just as fast.

2) Containing the .po files (translations) inside main/ cost 600Mb extra
for en-US developers to download. Suggestion keep the .po file away from
main in extras.

my opion: Translator work is NOT "extra", its an essential needed part for
our builds. In contrast to e.g. cliparts, the .po are part of the setup
package (of course transformed, similar to a C++ source).

My workflow can work, not as efficient with 1), but 2) breaks the workflow
for technical reasons (think of someone extracting en-US strings from an
updated /main to an old /extra and the published it to pootle == LOT of
extra translation in all languages.

I see translators working at the same level as developers, not as something
/extras, and therefore the work should be treated as such.

I have stopped work on further integration of genLang, until I either get
lazy consensus on my workflow, or we decide to go for another workflow.

thanks in advance for your comments (please all on dev@).

rgds
jan I.

Re: Question to all developers and translators: How integrated should translation be ?

Posted by Andre Fischer <aw...@gmail.com>.
On 06.09.2013 14:30, janI wrote:
> Hi
>
> I am copying this mail to the l10n list, in order to involve the
> translators that do not follow dev@. But lets please keep the discussion on
> dev@.
>
> As its hopefully known, I have been working on a new workflow for the whole
> translation process for quite a long time.
>
> Now I have released the first major part of the workflow, my ultimate
> commit has lead to some valid concerns from Jürgen and Herbert, this is the
> second time (during development) that I hear the essentially same concern.
>
> Therefore we a a community need to decide which road we want to follow.
>
> The workflow I am developing, would in the final phase look like (without
> technical details).
>
> 1) at regular intervals en-US text are extracted from our source tree,
> transferred to pootle as templates, and all languages are updates with
> new/changed/deleted keys. This part is partly manual (starting the build,
> updating the languages).
>
> 2) Translators work on pootle, Translator-comitters update languages in svn
> from pootle and start an offline language-pack build.
>
> 3) Translators test their translation using the binary from our buildbot  +
> language pack (translators debug tool). Turnaround time < 1 day.
>
> 4) Buildbot automatically include changed translations on regular builds
> (e.g. weekly).
>
> The 2 concerns that have been raised are:
> 1) Letting committers do "svn commit" and "svn up" directly in pootle,
> might produce a build breaker for our buildbots. Suggestion let an admin do
> it e.g. once a week.
>
> my opinion: We do not need an admin in the loop, we dont have a controlling
> for developers and they are even more likely to produce build breakers.
> Remember a .po file build breaker will only affect the language in question
> and can be repaired just as fast.

Keeping the admin out of the loop would be good.  But having SVN 
operations during every build would be bad.

If the commits and updates are done only on request by translators then 
that would be fine.  But if the build system does that on every build 
automatically , the overhead might be too large.

>
> 2) Containing the .po files (translations) inside main/ cost 600Mb extra
> for en-US developers to download. Suggestion keep the .po file away from
> main in extras.
>
> my opion: Translator work is NOT "extra", its an essential needed part for
> our builds. In contrast to e.g. cliparts, the .po are part of the setup
> package (of course transformed, similar to a C++ source).
>
> My workflow can work, not as efficient with 1), but 2) breaks the workflow
> for technical reasons (think of someone extracting en-US strings from an
> updated /main to an old /extra and the published it to pootle == LOT of
> extra translation in all languages.
>
> I see translators working at the same level as developers, not as something
> /extras, and therefore the work should be treated as such.

I think we should be a bit more specific here.  I agree that the work of 
translators and of developers is equally important.  But there are 
differences in their work flows that should not be neglected.  I am not 
a translator but I would expect that the majority of the work of 
translators is done in Pootle (online or offline).  Building OpenOffice 
seems more like a last step to verify the translation results.  In 
contrast developers build OpenOffice, or at least parts of it, on a 
regular basis.  Sometimes several times an hour.  That means that any 
slowdowns of the build process affect translators and developers quite 
differently.

I also think that each group does not need to integrate changes of the 
other too frequently.  When I fix a bug that does not affect any strings 
then translators are probably not very interested in it. That works the 
other way around as well.  I do most of my development work with en_US.  
I don't need frequent language updates to debug, fix, and verify bug 
fixes that are not language dependent.

So, keeping the things somewhat separated make sense.  But we should 
find names that do not imply that one part is more important than the other.

Best regards,
Andre


>
> I have stopped work on further integration of genLang, until I either get
> lazy consensus on my workflow, or we decide to go for another workflow.
>
> thanks in advance for your comments (please all on dev@).
>
> rgds
> jan I.
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

Posted by "Mr. Phan Anh" <pp...@gmail.com>.
What about let the customer choose it from the installation or after
the the installation and integrate a menu command such as "Apply
Vietnamese".
Both of those will need online.
By far, the world is online.
So, keeping this idea will avoid the problem, along with the function
such as "clip art".

On Fri, Sep 6, 2013 at 7:53 PM, Rob Weir <ro...@apache.org> wrote:
> On Fri, Sep 6, 2013 at 8:30 AM, janI <ja...@apache.org> wrote:
>> Hi
>>
>> I am copying this mail to the l10n list, in order to involve the
>> translators that do not follow dev@. But lets please keep the discussion on
>> dev@.
>>
>> As its hopefully known, I have been working on a new workflow for the whole
>> translation process for quite a long time.
>>
>> Now I have released the first major part of the workflow, my ultimate
>> commit has lead to some valid concerns from Jürgen and Herbert, this is the
>> second time (during development) that I hear the essentially same concern.
>>
>> Therefore we a a community need to decide which road we want to follow.
>>
>> The workflow I am developing, would in the final phase look like (without
>> technical details).
>>
>> 1) at regular intervals en-US text are extracted from our source tree,
>> transferred to pootle as templates, and all languages are updates with
>> new/changed/deleted keys. This part is partly manual (starting the build,
>> updating the languages).
>>
>> 2) Translators work on pootle, Translator-comitters update languages in svn
>> from pootle and start an offline language-pack build.
>>
>> 3) Translators test their translation using the binary from our buildbot  +
>> language pack (translators debug tool). Turnaround time < 1 day.
>>
>> 4) Buildbot automatically include changed translations on regular builds
>> (e.g. weekly).
>>
>> The 2 concerns that have been raised are:
>> 1) Letting committers do "svn commit" and "svn up" directly in pootle,
>> might produce a build breaker for our buildbots. Suggestion let an admin do
>> it e.g. once a week.
>>
>> my opinion: We do not need an admin in the loop, we dont have a controlling
>> for developers and they are even more likely to produce build breakers.
>> Remember a .po file build breaker will only affect the language in question
>> and can be repaired just as fast.
>>
>> 2) Containing the .po files (translations) inside main/ cost 600Mb extra
>> for en-US developers to download. Suggestion keep the .po file away from
>> main in extras.
>>
>> my opion: Translator work is NOT "extra", its an essential needed part for
>> our builds. In contrast to e.g. cliparts, the .po are part of the setup
>> package (of course transformed, similar to a C++ source).
>>
>
> I'd plan for growth here.  I see no reason why we will not end up with
> 100+ languages in the future.  Certainly there were that many with
> OpenOffice.org.  So if we have 600Mb for 25 or so languages, will it
> still be a reasonable layout when the languages take up 2.4 GB?
>
> -Rob
>
>
>
>> My workflow can work, not as efficient with 1), but 2) breaks the workflow
>> for technical reasons (think of someone extracting en-US strings from an
>> updated /main to an old /extra and the published it to pootle == LOT of
>> extra translation in all languages.
>>
>> I see translators working at the same level as developers, not as something
>> /extras, and therefore the work should be treated as such.
>>
>> I have stopped work on further integration of genLang, until I either get
>> lazy consensus on my workflow, or we decide to go for another workflow.
>>
>> thanks in advance for your comments (please all on dev@).
>>
>> rgds
>> jan I.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

Posted by Rob Weir <ro...@apache.org>.
On Fri, Sep 6, 2013 at 8:30 AM, janI <ja...@apache.org> wrote:
> Hi
>
> I am copying this mail to the l10n list, in order to involve the
> translators that do not follow dev@. But lets please keep the discussion on
> dev@.
>
> As its hopefully known, I have been working on a new workflow for the whole
> translation process for quite a long time.
>
> Now I have released the first major part of the workflow, my ultimate
> commit has lead to some valid concerns from Jürgen and Herbert, this is the
> second time (during development) that I hear the essentially same concern.
>
> Therefore we a a community need to decide which road we want to follow.
>
> The workflow I am developing, would in the final phase look like (without
> technical details).
>
> 1) at regular intervals en-US text are extracted from our source tree,
> transferred to pootle as templates, and all languages are updates with
> new/changed/deleted keys. This part is partly manual (starting the build,
> updating the languages).
>
> 2) Translators work on pootle, Translator-comitters update languages in svn
> from pootle and start an offline language-pack build.
>
> 3) Translators test their translation using the binary from our buildbot  +
> language pack (translators debug tool). Turnaround time < 1 day.
>
> 4) Buildbot automatically include changed translations on regular builds
> (e.g. weekly).
>
> The 2 concerns that have been raised are:
> 1) Letting committers do "svn commit" and "svn up" directly in pootle,
> might produce a build breaker for our buildbots. Suggestion let an admin do
> it e.g. once a week.
>
> my opinion: We do not need an admin in the loop, we dont have a controlling
> for developers and they are even more likely to produce build breakers.
> Remember a .po file build breaker will only affect the language in question
> and can be repaired just as fast.
>
> 2) Containing the .po files (translations) inside main/ cost 600Mb extra
> for en-US developers to download. Suggestion keep the .po file away from
> main in extras.
>
> my opion: Translator work is NOT "extra", its an essential needed part for
> our builds. In contrast to e.g. cliparts, the .po are part of the setup
> package (of course transformed, similar to a C++ source).
>

I'd plan for growth here.  I see no reason why we will not end up with
100+ languages in the future.  Certainly there were that many with
OpenOffice.org.  So if we have 600Mb for 25 or so languages, will it
still be a reasonable layout when the languages take up 2.4 GB?

-Rob



> My workflow can work, not as efficient with 1), but 2) breaks the workflow
> for technical reasons (think of someone extracting en-US strings from an
> updated /main to an old /extra and the published it to pootle == LOT of
> extra translation in all languages.
>
> I see translators working at the same level as developers, not as something
> /extras, and therefore the work should be treated as such.
>
> I have stopped work on further integration of genLang, until I either get
> lazy consensus on my workflow, or we decide to go for another workflow.
>
> thanks in advance for your comments (please all on dev@).
>
> rgds
> jan I.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

Posted by janI <ja...@apache.org>.
On Sep 6, 2013 11:40 PM, "Aivaras Stepukonis" <as...@gmail.com> wrote:
>
> Is this a command line? Please, instruct me as it is an area that I
haven't explored yet. Will it count characters as opposed to words? I'm
eager to learn.

yes its ubuntu (or cygwin) commandline.

command wc counts bytes, words and lines.

rgds
jan i
>
> Aivaras
>
> 2013.09.07 00:30, janI rašė:
>
>> On Sep 6, 2013 8:44 PM, "Aivaras Stepukonis" <as...@gmail.com>
wrote:
>>>
>>> Yea, but that involves opening files one-by-one, counting their stats
and
>>
>> adding them up. I was hoping for an automatic way to determine the
>> character count of the whole translatable text.
>>
>> whats wrong about :
>>
>> grep msgid *.po | wc

>>
>> rgds
>> jan i
>>
>>> Aivaras
>>>
>>> 2013.09.06 19:17, janI rašė:
>>>>
>>>> On 6 September 2013 15:18, Aivaras Stepukonis <as...@gmail.com>
>>
>> wrote:
>>>>>
>>>>> Is there an easy way to get the stats about the translatable text
files
>>
>> of
>>>>>
>>>>> AOO. I want to know the character count for both the main translation
>>
>> text
>>>>>
>>>>> and the help files (in the English source).
>>>>>
>>>>> Download the po files and do whatever you need, thats what I am doing.
>>>>
>>>> rgds
>>>> jan I.
>>>>
>>>>
>>>>> Aivaras
>>>>>
>>>>>
>>>>> --------------------------
>>
>> ----**------------------------------**---------
>>>>>
>>>>> To unsubscribe, e-mail: l10n-unsubscribe@openoffice.**apache.org<
>>
>> l10n-unsubscribe@openoffice.apache.org>
>>>>>
>>>>> For additional commands, e-mail: l10n-help@openoffice.apache.**org<
>>
>> l10n-help@openoffice.apache.org>
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: l10n-help@openoffice.apache.org
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: l10n-help@openoffice.apache.org
>

Re: Question to all developers and translators: How integrated should translation be ?

Posted by Aivaras Stepukonis <as...@gmail.com>.
Is this a command line? Please, instruct me as it is an area that I 
haven't explored yet. Will it count characters as opposed to words? I'm 
eager to learn.

Aivaras

2013.09.07 00:30, janI rašė:
> On Sep 6, 2013 8:44 PM, "Aivaras Stepukonis" <as...@gmail.com> wrote:
>> Yea, but that involves opening files one-by-one, counting their stats and
> adding them up. I was hoping for an automatic way to determine the
> character count of the whole translatable text.
>
> whats wrong about :
>
> grep msgid *.po | wc
>
> rgds
> jan i
>
>> Aivaras
>>
>> 2013.09.06 19:17, janI rašė:
>>> On 6 September 2013 15:18, Aivaras Stepukonis <as...@gmail.com>
> wrote:
>>>> Is there an easy way to get the stats about the translatable text files
> of
>>>> AOO. I want to know the character count for both the main translation
> text
>>>> and the help files (in the English source).
>>>>
>>>> Download the po files and do whatever you need, thats what I am doing.
>>> rgds
>>> jan I.
>>>
>>>
>>>> Aivaras
>>>>
>>>>
>>>> --------------------------
> ----**------------------------------**---------
>>>> To unsubscribe, e-mail: l10n-unsubscribe@openoffice.**apache.org<
> l10n-unsubscribe@openoffice.apache.org>
>>>> For additional commands, e-mail: l10n-help@openoffice.apache.**org<
> l10n-help@openoffice.apache.org>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: l10n-help@openoffice.apache.org
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
For additional commands, e-mail: l10n-help@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

Posted by janI <ja...@apache.org>.
On Sep 6, 2013 8:44 PM, "Aivaras Stepukonis" <as...@gmail.com> wrote:
>
> Yea, but that involves opening files one-by-one, counting their stats and
adding them up. I was hoping for an automatic way to determine the
character count of the whole translatable text.

whats wrong about :

grep msgid *.po | wc

rgds
jan i

>
> Aivaras
>
> 2013.09.06 19:17, janI rašė:
>>
>> On 6 September 2013 15:18, Aivaras Stepukonis <as...@gmail.com>
wrote:
>>
>>> Is there an easy way to get the stats about the translatable text files
of
>>> AOO. I want to know the character count for both the main translation
text
>>> and the help files (in the English source).
>>>
>>> Download the po files and do whatever you need, thats what I am doing.
>>
>> rgds
>> jan I.
>>
>>
>>> Aivaras
>>>
>>>
>>> --------------------------
----**------------------------------**---------
>>> To unsubscribe, e-mail: l10n-unsubscribe@openoffice.**apache.org<
l10n-unsubscribe@openoffice.apache.org>
>>> For additional commands, e-mail: l10n-help@openoffice.apache.**org<
l10n-help@openoffice.apache.org>
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: l10n-help@openoffice.apache.org
>

Re: Question to all developers and translators: How integrated should translation be ?

Posted by Aivaras Stepukonis <as...@gmail.com>.
Yea, but that involves opening files one-by-one, counting their stats 
and adding them up. I was hoping for an automatic way to determine the 
character count of the whole translatable text.

Aivaras

2013.09.06 19:17, janI rašė:
> On 6 September 2013 15:18, Aivaras Stepukonis <as...@gmail.com> wrote:
>
>> Is there an easy way to get the stats about the translatable text files of
>> AOO. I want to know the character count for both the main translation text
>> and the help files (in the English source).
>>
>> Download the po files and do whatever you need, thats what I am doing.
> rgds
> jan I.
>
>
>> Aivaras
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: l10n-unsubscribe@openoffice.**apache.org<l1...@openoffice.apache.org>
>> For additional commands, e-mail: l10n-help@openoffice.apache.**org<l1...@openoffice.apache.org>
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
For additional commands, e-mail: l10n-help@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

Posted by janI <ja...@apache.org>.
On 6 September 2013 15:18, Aivaras Stepukonis <as...@gmail.com> wrote:

> Is there an easy way to get the stats about the translatable text files of
> AOO. I want to know the character count for both the main translation text
> and the help files (in the English source).
>
> Download the po files and do whatever you need, thats what I am doing.

rgds
jan I.


> Aivaras
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: l10n-unsubscribe@openoffice.**apache.org<l1...@openoffice.apache.org>
> For additional commands, e-mail: l10n-help@openoffice.apache.**org<l1...@openoffice.apache.org>
>
>

Re: Question to all developers and translators: How integrated should translation be ?

Posted by Aivaras Stepukonis <as...@gmail.com>.
Is there an easy way to get the stats about the translatable text files 
of AOO. I want to know the character count for both the main translation 
text and the help files (in the English source).

Aivaras

---------------------------------------------------------------------
To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
For additional commands, e-mail: l10n-help@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

Posted by Aivaras Stepukonis <as...@gmail.com>.
2013.09.06 15:30, janI rašė:
> Hi
>
> I am copying this mail to the l10n list, in order to involve the
> translators that do not follow dev@. But lets please keep the discussion on
> dev@.
>
> As its hopefully known, I have been working on a new workflow for the whole
> translation process for quite a long time.
>
> Now I have released the first major part of the workflow, my ultimate
> commit has lead to some valid concerns from Jürgen and Herbert, this is the
> second time (during development) that I hear the essentially same concern.
>
> Therefore we a a community need to decide which road we want to follow.
>
> The workflow I am developing, would in the final phase look like (without
> technical details).
>
> 1) at regular intervals en-US text are extracted from our source tree,
> transferred to pootle as templates, and all languages are updates with
> new/changed/deleted keys. This part is partly manual (starting the build,
> updating the languages).
>
> 2) Translators work on pootle, Translator-comitters update languages in svn
> from pootle and start an offline language-pack build.
>
> 3) Translators test their translation using the binary from our buildbot  +
> language pack (translators debug tool). Turnaround time < 1 day.
>
> 4) Buildbot automatically include changed translations on regular builds
> (e.g. weekly).
>
> The 2 concerns that have been raised are:
> 1) Letting committers do "svn commit" and "svn up" directly in pootle,
> might produce a build breaker for our buildbots. Suggestion let an admin do
> it e.g. once a week.
>
> my opinion: We do not need an admin in the loop, we dont have a controlling
> for developers and they are even more likely to produce build breakers.
> Remember a .po file build breaker will only affect the language in question
> and can be repaired just as fast.
>
> 2) Containing the .po files (translations) inside main/ cost 600Mb extra
> for en-US developers to download. Suggestion keep the .po file away from
> main in extras.
>
> my opion: Translator work is NOT "extra", its an essential needed part for
> our builds. In contrast to e.g. cliparts, the .po are part of the setup
> package (of course transformed, similar to a C++ source).
>
> My workflow can work, not as efficient with 1), but 2) breaks the workflow
> for technical reasons (think of someone extracting en-US strings from an
> updated /main to an old /extra and the published it to pootle == LOT of
> extra translation in all languages.
>
> I see translators working at the same level as developers, not as something
> /extras, and therefore the work should be treated as such.
This premise cannot be stressed enough! I'd even go as far as to say, 
that they're as much developers as their programming colleagues, the 
differences being that they're developing the part of software that 
relies on natural language while the programmers are developing the part 
that relies on artificial language. The morale? The "translatability" of 
the software should be planned at the architectural stage of software 
development and translators should be part of that stage.

I'll file up a separate issue on this topic in a couple of weeks when I 
have more time.
>
> I have stopped work on further integration of genLang, until I either get
> lazy consensus on my workflow, or we decide to go for another workflow.
>
> thanks in advance for your comments (please all on dev@).
>
> rgds
> jan I.
>


---------------------------------------------------------------------
To unsubscribe, e-mail: l10n-unsubscribe@openoffice.apache.org
For additional commands, e-mail: l10n-help@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

Posted by Andre Fischer <aw...@gmail.com>.
On 06.09.2013 15:20, Herbert Duerr wrote:
> On 06.09.2013 15:03, Rob Weir wrote:
>> So maybe just rename "extras" to something else if it is merely the
>> word that is offensive.   But although translations are essential to
>> the project, modularity is also important.  For example, we don't put
>> the website in /main do we, although that is important to the project?
>
> Yes, "main" should be renamed to "source" or "src" as this name is too 
> presumptuous and I understand why not being in main is considered 
> discriminatory. Having a dedicated "source" directory would also help 
> to give our repository a more common structure for an open source 
> project.
>
> In "extras" we could have templates, clip arts, example documents, etc.

Maybe we should rename that, too, maybe to "data".  Contributors who 
create templates or clip arts are important for our community as well.

-Andre

>
> And "l10n" deserves its own directory tree.
>
> Herbert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

Posted by Herbert Duerr <hd...@apache.org>.
On 06.09.2013 15:03, Rob Weir wrote:
> So maybe just rename "extras" to something else if it is merely the
> word that is offensive.   But although translations are essential to
> the project, modularity is also important.  For example, we don't put
> the website in /main do we, although that is important to the project?

Yes, "main" should be renamed to "source" or "src" as this name is too 
presumptuous and I understand why not being in main is considered 
discriminatory. Having a dedicated "source" directory would also help to 
give our repository a more common structure for an open source project.

In "extras" we could have templates, clip arts, example documents, etc.

And "l10n" deserves its own directory tree.

Herbert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

Posted by Rob Weir <ro...@apache.org>.
On Fri, Sep 6, 2013 at 8:54 AM, Armin Le Grand <Ar...@me.com> wrote:
> I see translators working at the same level as developers, not as something
>>>
>>> /extras, and therefore the work should be treated as such.
>>
>>
>> It is not ;-) My wife is a translator, I can tell you...
>
> Upps... Before anyone may get that wrong - I clearly meant here that I also
> see it as the same and I treat it the same.
>

So maybe just rename "extras" to something else if it is merely the
word that is offensive.   But although translations are essential to
the project, modularity is also important.  For example, we don't put
the website in /main do we, although that is important to the project?

-Rob


> --
> ALG
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

Posted by Armin Le Grand <Ar...@me.com>.
I see translators working at the same level as developers, not as something
>> /extras, and therefore the work should be treated as such.
>
> It is not ;-) My wife is a translator, I can tell you...
Upps... Before anyone may get that wrong - I clearly meant here that I 
also see it as the same and I treat it the same.
--
ALG

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

Posted by Armin Le Grand <Ar...@me.com>.
     Hi Jan,

On 06.09.2013 14:30, janI wrote:
> Hi
>
> I am copying this mail to the l10n list, in order to involve the
> translators that do not follow dev@. But lets please keep the discussion on
> dev@.
>
> As its hopefully known, I have been working on a new workflow for the whole
> translation process for quite a long time.

Yes, fine thing. Looking forward to it!

> Now I have released the first major part of the workflow, my ultimate
> commit has lead to some valid concerns from Jürgen and Herbert, this is the
> second time (during development) that I hear the essentially same concern.
>
> Therefore we a a community need to decide which road we want to follow.
>
> The workflow I am developing, would in the final phase look like (without
> technical details).
>
> 1) at regular intervals en-US text are extracted from our source tree,
> transferred to pootle as templates, and all languages are updates with
> new/changed/deleted keys. This part is partly manual (starting the build,
> updating the languages).
>
> 2) Translators work on pootle, Translator-comitters update languages in svn
> from pootle and start an offline language-pack build.
>
> 3) Translators test their translation using the binary from our buildbot  +
> language pack (translators debug tool). Turnaround time < 1 day.
>
> 4) Buildbot automatically include changed translations on regular builds
> (e.g. weekly).
>
> The 2 concerns that have been raised are:
> 1) Letting committers do "svn commit" and "svn up" directly in pootle,
> might produce a build breaker for our buildbots. Suggestion let an admin do
> it e.g. once a week.
>
> my opinion: We do not need an admin in the loop, we dont have a controlling
> for developers and they are even more likely to produce build breakers.
> Remember a .po file build breaker will only affect the language in question
> and can be repaired just as fast.

+1, not really avoidable. Producing BuldBreakes is a fast teacher to get 
better/more careful. The alternative is too complicated.

> 2) Containing the .po files (translations) inside main/ cost 600Mb extra
> for en-US developers to download. Suggestion keep the .po file away from
> main in extras.
>
> my opion: Translator work is NOT "extra", its an essential needed part for
> our builds. In contrast to e.g. cliparts, the .po are part of the setup
> package (of course transformed, similar to a C++ source).

Well, the goal is to keep stuff as simple as possible when we want to 
attract new developers. Size of the checkout is one criteria of 
'simple'. The build and stuff to checkout is already too big, reducing 
it would be better than making it bigger.
Plese do not take the name 'extra' wordly, there are many necessary and 
valuable things; take it the other way around: The non-extra should be 
the minimal set to be able to work on the office as a developer.
Thus, I would prefer to keep main small. Maybe a new dir tree besides 
main and extra ('translation', 'languages', ...) would be good and 
self-explanatory.

>
> My workflow can work, not as efficient with 1), but 2) breaks the workflow
> for technical reasons (think of someone extracting en-US strings from an
> updated /main to an old /extra and the published it to pootle == LOT of
> extra translation in all languages.
>
> I see translators working at the same level as developers, not as something
> /extras, and therefore the work should be treated as such.

It is not ;-) My wife is a translator, I can tell you...

> I have stopped work on further integration of genLang, until I either get
> lazy consensus on my workflow, or we decide to go for another workflow.
>
> thanks in advance for your comments (please all on dev@).

If it would not cause too much work to put that 600mb besides main I 
would appreciate it. If it's much extra work, keep it as it is.

>
> rgds
> jan I.
Sincerely,
     Armin

--
ALG

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

Posted by Rob Weir <ro...@apache.org>.
On Fri, Sep 6, 2013 at 12:33 PM, janI <ja...@apache.org> wrote:
> On 6 September 2013 16:53, Dick Groskamp <th...@quicknet.nl> wrote:
>
>> Op 6-9-2013 14:30, janI schreef:
>>
>>  Hi
>>>
>>> I am copying this mail to the l10n list, in order to involve the
>>> translators that do not follow dev@. But lets please keep the discussion
>>> on
>>> dev@.
>>>
>>> As its hopefully known, I have been working on a new workflow for the
>>> whole
>>> translation process for quite a long time.
>>>
>>> Now I have released the first major part of the workflow, my ultimate
>>> commit has lead to some valid concerns from Jürgen and Herbert, this is
>>> the
>>> second time (during development) that I hear the essentially same concern.
>>>
>>> Therefore we a a community need to decide which road we want to follow.
>>>
>>> The workflow I am developing, would in the final phase look like (without
>>> technical details).
>>>
>>> 1) at regular intervals en-US text are extracted from our source tree,
>>> transferred to pootle as templates, and all languages are updates with
>>> new/changed/deleted keys. This part is partly manual (starting the build,
>>> updating the languages).
>>>
>>> 2) Translators work on pootle, Translator-comitters update languages in
>>> svn
>>> from pootle and start an offline language-pack build.
>>>
>>> 3) Translators test their translation using the binary from our buildbot
>>>  +
>>> language pack (translators debug tool). Turnaround time < 1 day.
>>>
>>> 4) Buildbot automatically include changed translations on regular builds
>>> (e.g. weekly).
>>>
>>> The 2 concerns that have been raised are:
>>> 1) Letting committers do "svn commit" and "svn up" directly in pootle,
>>> might produce a build breaker for our buildbots. Suggestion let an admin
>>> do
>>> it e.g. once a week.
>>>
>>> my opinion: We do not need an admin in the loop, we dont have a
>>> controlling
>>> for developers and they are even more likely to produce build breakers.
>>> Remember a .po file build breaker will only affect the language in
>>> question
>>> and can be repaired just as fast.
>>>
>>> 2) Containing the .po files (translations) inside main/ cost 600Mb extra
>>> for en-US developers to download. Suggestion keep the .po file away from
>>> main in extras.
>>>
>>> my opion: Translator work is NOT "extra", its an essential needed part for
>>> our builds. In contrast to e.g. cliparts, the .po are part of the setup
>>> package (of course transformed, similar to a C++ source).
>>>
>>> My workflow can work, not as efficient with 1), but 2) breaks the workflow
>>> for technical reasons (think of someone extracting en-US strings from an
>>> updated /main to an old /extra and the published it to pootle == LOT of
>>> extra translation in all languages.
>>>
>>> I see translators working at the same level as developers, not as
>>> something
>>> /extras, and therefore the work should be treated as such.
>>>
>>> I have stopped work on further integration of genLang, until I either get
>>> lazy consensus on my workflow, or we decide to go for another workflow.
>>>
>>> thanks in advance for your comments (please all on dev@).
>>>
>>> rgds
>>> jan I.
>>>
>>>  In general I have no problem with this workflow and think
>> it might speed up things for the builders side of the proces.
>>
>> The only problem I have is that I'm no techie and SVN is, to be honest,
>> to complicated for me.
>>
>> Would it be possible, for instance after the deadline for translation has
>> passed,
>> for a builder/developer/admin to update ALL languages from POOTLE?
>>
>> I think with something like that we would have have ALL alterations into
>> SVN
>> at once.
>> Mind you I have no idea how much work that would be, but it seems
>> to me it gives some assurance about the imported strings.
>>
>> --
>> DiGro
>> ___________________________
>> Apache OpenOffice 4.0.0 (Dutch) and scanned with Ziggo extended security
>> (F-Secure)
>>
>> thanks for all the comments so far, I am real impressed.
>
> I have to correct/clarify a couple of things.
>
> 1) the build process will not and should not do "svn commit", that are done
> by manually by developers and translator-committers when they feel their
> part is ready (just as developers do).
>
> 2) The emotional part of being in /main or /extra is very important, and
> one I fight for. But equally important it that my workflow will not work
> safely, if it works with 2 svn trees. The chances that someone does a build
> in /main with an not updated /extra (because he/she dont care) is too high,
> and the consequences are down right frightening. If it happes, it might
> change the translation templates, which again changes all language files,
> which ultimately calls for translators to translate false texts. Is that
> really wanted ?
>
> 3) There are absolutely no need to separate at svn/git level, but systems
> have a .ignore facility so directory can be ignored and left empty (which
> would be no problem for my workflow) so any developer not wanting the full
> package, can still do a "svn co main" and limit to what is wanted. Btw I
> dont need MAC development, why do I have to dowload that ?
>
> 4) When we walk about making the system modular, and want to separate e.g.
> connectivity.po from /main/connectivity, we could use the same argument to
> move all .src files away from main, in both cases we cannot generate a full
> AOO installation. Actually modern modularity would call for the .src files
> (and others) to contain the KID code, so  that en-US could be translated as
> well. We assume that our developers speak perfect en-US, which I think is
> far from the case (remember the ripples when a developer changes the en-US
> strings, ALL languages have to be updated).
>
> I will of course wait the 72 hours, but it seems to me that there are no
> real consensus about integrating my proposed workflow (which NEEDS
> integrated po files).
>

It has only been 5 hours.  Let's wait for at least 10% of 72 hours to
pass before drawing conclusions ;-)

-Rob


> rgds
> jan i.
>
>
>
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

Posted by Andrea Pescetti <pe...@apache.org>.
Jürgen Schmidt wrote:
> On 9/6/13 6:33 PM, janI wrote:
>> 2) The emotional part of being in /main or /extra is very important, and
>> one I fight for. But equally important it that my workflow will not work
>> safely, if it works with 2 svn trees. The chances that someone does a build
>> in /main with an not updated /extra (because he/she dont care) is too high...
>
> If I am interested in language builds I check out trunk which includes
> main and extras. So I am safe an I know what I am doing and expect that
> other developers know what they are doing as well.

I'm a big fan of localization, and extremely happy to see a tool that 
will eventually allow translators to have timely feedback on their work 
and will be a key factor in enlarging our community. Thanks Jan for the 
part already done and looking forward to seeing the rest.

I've never paid much attention to the "main / extras" subdivision: I 
always checkout trunk (or the full branch), update trunk and see it as 
one thing. I've never seen the name "extra" as meaning "this is stuff 
you can ignore", but as meaning "this is stuff that you won't open in 
your IDE" (if not else, because trunk still has the SDF files which tend 
to be very heavy to process with editors). Similarly, I've never seen 
"main" as meaning "all the rest is worth less". Our released source code 
tarball, of course, contains both "main" and "extras", and there are no 
cases where "main" is treated any differently than "extras": they are 
just names.

Since extras only contains l10n at the moment, having "main" and 
"languages" at the same level would be fine for me. Herbert's suggestion 
of renaming "main" to "source" makes a lot of sense too, but I don't 
know how many wiki pages / build guides would have to be updated to fix 
that detail. I'm not a big fan of having "languages" within "main" since 
stuff should move out of "main", not into it, and with two separate 
paths it's easier to track history and logs. But again, the repository 
for me is the full "trunk" or branch, I've never checked out just of 
subdirectory of it.

Remark about the size discussion: Italian is 100% translated and it 
takes less than 3 MBytes (plus SVN overhead). The "languages" folder 
already contains all complete and incomplete languages, so it's really 
unlikely to grow in the foreseeable future to numbers similar to what 
Rob imagined.

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

Posted by Armin Le Grand <Ar...@me.com>.
     Hi list,

On 10.09.2013 16:18, Jürgen Schmidt wrote:

[stuff deleted here]
> I see consensus on the general workflow and the only point where we 
> disagree is the location of the po files. A still minor detail from my 
> point of view but anyway. Juergen 

Not a minor detail; it may get huge over time. Rob wrote:

'I'd plan for growth here. I see no reason why we will not end up with 
100+ languages in the future. Certainly there were that many with 
OpenOffice.org. So if we have 600Mb for 25 or so languages, will it 
still be a reasonable layout when the languages take up 2.4 GB?'

And he is right. Sooner or later it has to move to a point in the tree 
where it is not required to download it when you want to work on the 
implementaition side. Why not do it now, from the beginning? We were all 
happy to get rid of binfilter so the source to download got smaller, do 
we want to blow it up again when only en-US will be used for building? 
Another thought: It costs ressources - time, bandwidth, space on 
everyones devices, on the servers - and thus energy in real life. I for 
myself feel much better since we do no longer copy around binfilter, not 
at last for a better ecologicat footprint --- please rethink putting it 
in a decent place (whatever name) where for each usage only the needed 
stuff needs to be downloaded, and be again ensured that this has nothing 
to do with the value of different classes of contributions (which do not 
exist from my POV).

Do I feel bad when someone only checks out a single *.po file, but not 
the sources I was so hardly working on...? No, of course not :-)
Just my 2 cents...

Sincerely,
     Armin

[more stuff deleted here]
--
ALG

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

Posted by Jürgen Schmidt <jo...@gmail.com>.
On 9/6/13 6:33 PM, janI wrote:
> On 6 September 2013 16:53, Dick Groskamp <th...@quicknet.nl> wrote:
> 
>> Op 6-9-2013 14:30, janI schreef:
>>
>>  Hi
>>>
>>> I am copying this mail to the l10n list, in order to involve the
>>> translators that do not follow dev@. But lets please keep the discussion
>>> on
>>> dev@.
>>>
>>> As its hopefully known, I have been working on a new workflow for the
>>> whole
>>> translation process for quite a long time.
>>>
>>> Now I have released the first major part of the workflow, my ultimate
>>> commit has lead to some valid concerns from Jürgen and Herbert, this is
>>> the
>>> second time (during development) that I hear the essentially same concern.
>>>
>>> Therefore we a a community need to decide which road we want to follow.
>>>
>>> The workflow I am developing, would in the final phase look like (without
>>> technical details).
>>>
>>> 1) at regular intervals en-US text are extracted from our source tree,
>>> transferred to pootle as templates, and all languages are updates with
>>> new/changed/deleted keys. This part is partly manual (starting the build,
>>> updating the languages).
>>>
>>> 2) Translators work on pootle, Translator-comitters update languages in
>>> svn
>>> from pootle and start an offline language-pack build.
>>>
>>> 3) Translators test their translation using the binary from our buildbot
>>>  +
>>> language pack (translators debug tool). Turnaround time < 1 day.
>>>
>>> 4) Buildbot automatically include changed translations on regular builds
>>> (e.g. weekly).
>>>
>>> The 2 concerns that have been raised are:
>>> 1) Letting committers do "svn commit" and "svn up" directly in pootle,
>>> might produce a build breaker for our buildbots. Suggestion let an admin
>>> do
>>> it e.g. once a week.
>>>
>>> my opinion: We do not need an admin in the loop, we dont have a
>>> controlling
>>> for developers and they are even more likely to produce build breakers.
>>> Remember a .po file build breaker will only affect the language in
>>> question
>>> and can be repaired just as fast.
>>>
>>> 2) Containing the .po files (translations) inside main/ cost 600Mb extra
>>> for en-US developers to download. Suggestion keep the .po file away from
>>> main in extras.
>>>
>>> my opion: Translator work is NOT "extra", its an essential needed part for
>>> our builds. In contrast to e.g. cliparts, the .po are part of the setup
>>> package (of course transformed, similar to a C++ source).
>>>
>>> My workflow can work, not as efficient with 1), but 2) breaks the workflow
>>> for technical reasons (think of someone extracting en-US strings from an
>>> updated /main to an old /extra and the published it to pootle == LOT of
>>> extra translation in all languages.
>>>
>>> I see translators working at the same level as developers, not as
>>> something
>>> /extras, and therefore the work should be treated as such.
>>>
>>> I have stopped work on further integration of genLang, until I either get
>>> lazy consensus on my workflow, or we decide to go for another workflow.
>>>
>>> thanks in advance for your comments (please all on dev@).
>>>
>>> rgds
>>> jan I.
>>>
>>>  In general I have no problem with this workflow and think
>> it might speed up things for the builders side of the proces.
>>
>> The only problem I have is that I'm no techie and SVN is, to be honest,
>> to complicated for me.
>>
>> Would it be possible, for instance after the deadline for translation has
>> passed,
>> for a builder/developer/admin to update ALL languages from POOTLE?
>>
>> I think with something like that we would have have ALL alterations into
>> SVN
>> at once.
>> Mind you I have no idea how much work that would be, but it seems
>> to me it gives some assurance about the imported strings.
>>
>> --
>> DiGro
>> ___________________________
>> Apache OpenOffice 4.0.0 (Dutch) and scanned with Ziggo extended security
>> (F-Secure)
>>
>> thanks for all the comments so far, I am real impressed.
> 
> I have to correct/clarify a couple of things.
> 
> 1) the build process will not and should not do "svn commit", that are done
> by manually by developers and translator-committers when they feel their
> part is ready (just as developers do).

good

> 
> 2) The emotional part of being in /main or /extra is very important, and
> one I fight for. But equally important it that my workflow will not work
> safely, if it works with 2 svn trees. The chances that someone does a build
> in /main with an not updated /extra (because he/she dont care) is too high,
> and the consequences are down right frightening. If it happes, it might
> change the translation templates, which again changes all language files,
> which ultimately calls for translators to translate false texts. Is that
> really wanted ?

I don't really get your point, if a developer/translator don't care
about what he is doing the risk that he damage something is always very
high.

If I am interested in language builds I check out trunk which includes
main and extras. So I am safe an I know what I am doing and expect that
other developers know what they are doing as well.

Translators probably never build on their own and use nightly builds
from the build bots. The build env ensures that trunk or whatever common
root (branch or tag) is updated correctly before the build starts.

I see no real problem here.


> 
> 3) There are absolutely no need to separate at svn/git level, but systems
> have a .ignore facility so directory can be ignored and left empty (which
> would be no problem for my workflow) so any developer not wanting the full
> package, can still do a "svn co main" and limit to what is wanted. Btw I
> dont need MAC development, why do I have to dowload that ?

the code necessary for certain platforms is integrated all over and it
is far to complicate to extract this. Possible but I see no advantage
here at this time.
The handling with ignore file is far more error prone to me ...

> 
> 4) When we walk about making the system modular, and want to separate e.g.
> connectivity.po from /main/connectivity, we could use the same argument to
> move all .src files away from main, in both cases we cannot generate a full
> AOO installation. Actually modern modularity would call for the .src files
> (and others) to contain the KID code, so  that en-US could be translated as
> well. We assume that our developers speak perfect en-US, which I think is
> far from the case (remember the ripples when a developer changes the en-US
> strings, ALL languages have to be updated).
> 

I don't think so, en-US was chosen as the development language and it is
part of the source directly. It's not only src files but en-US strings
are also config files, help files, property files etc.

I don't see why your proposed workflow should not work with having the
po files in a separate directory whatever the name would be.

I see consensus on the general workflow and the only point where we
disagree is the location of the po files. A still minor detail from my
point of view but anyway.

Juergen


> I will of course wait the 72 hours, but it seems to me that there are no
> real consensus about integrating my proposed workflow (which NEEDS
> integrated po files).
> 
> rgds
> jan i.
> 
> 
> 
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Question to all developers and translators: How integrated should translation be ?

Posted by janI <ja...@apache.org>.
On 6 September 2013 16:53, Dick Groskamp <th...@quicknet.nl> wrote:

> Op 6-9-2013 14:30, janI schreef:
>
>  Hi
>>
>> I am copying this mail to the l10n list, in order to involve the
>> translators that do not follow dev@. But lets please keep the discussion
>> on
>> dev@.
>>
>> As its hopefully known, I have been working on a new workflow for the
>> whole
>> translation process for quite a long time.
>>
>> Now I have released the first major part of the workflow, my ultimate
>> commit has lead to some valid concerns from Jürgen and Herbert, this is
>> the
>> second time (during development) that I hear the essentially same concern.
>>
>> Therefore we a a community need to decide which road we want to follow.
>>
>> The workflow I am developing, would in the final phase look like (without
>> technical details).
>>
>> 1) at regular intervals en-US text are extracted from our source tree,
>> transferred to pootle as templates, and all languages are updates with
>> new/changed/deleted keys. This part is partly manual (starting the build,
>> updating the languages).
>>
>> 2) Translators work on pootle, Translator-comitters update languages in
>> svn
>> from pootle and start an offline language-pack build.
>>
>> 3) Translators test their translation using the binary from our buildbot
>>  +
>> language pack (translators debug tool). Turnaround time < 1 day.
>>
>> 4) Buildbot automatically include changed translations on regular builds
>> (e.g. weekly).
>>
>> The 2 concerns that have been raised are:
>> 1) Letting committers do "svn commit" and "svn up" directly in pootle,
>> might produce a build breaker for our buildbots. Suggestion let an admin
>> do
>> it e.g. once a week.
>>
>> my opinion: We do not need an admin in the loop, we dont have a
>> controlling
>> for developers and they are even more likely to produce build breakers.
>> Remember a .po file build breaker will only affect the language in
>> question
>> and can be repaired just as fast.
>>
>> 2) Containing the .po files (translations) inside main/ cost 600Mb extra
>> for en-US developers to download. Suggestion keep the .po file away from
>> main in extras.
>>
>> my opion: Translator work is NOT "extra", its an essential needed part for
>> our builds. In contrast to e.g. cliparts, the .po are part of the setup
>> package (of course transformed, similar to a C++ source).
>>
>> My workflow can work, not as efficient with 1), but 2) breaks the workflow
>> for technical reasons (think of someone extracting en-US strings from an
>> updated /main to an old /extra and the published it to pootle == LOT of
>> extra translation in all languages.
>>
>> I see translators working at the same level as developers, not as
>> something
>> /extras, and therefore the work should be treated as such.
>>
>> I have stopped work on further integration of genLang, until I either get
>> lazy consensus on my workflow, or we decide to go for another workflow.
>>
>> thanks in advance for your comments (please all on dev@).
>>
>> rgds
>> jan I.
>>
>>  In general I have no problem with this workflow and think
> it might speed up things for the builders side of the proces.
>
> The only problem I have is that I'm no techie and SVN is, to be honest,
> to complicated for me.
>
> Would it be possible, for instance after the deadline for translation has
> passed,
> for a builder/developer/admin to update ALL languages from POOTLE?
>
> I think with something like that we would have have ALL alterations into
> SVN
> at once.
> Mind you I have no idea how much work that would be, but it seems
> to me it gives some assurance about the imported strings.
>
> --
> DiGro
> ___________________________
> Apache OpenOffice 4.0.0 (Dutch) and scanned with Ziggo extended security
> (F-Secure)
>
> thanks for all the comments so far, I am real impressed.

I have to correct/clarify a couple of things.

1) the build process will not and should not do "svn commit", that are done
by manually by developers and translator-committers when they feel their
part is ready (just as developers do).

2) The emotional part of being in /main or /extra is very important, and
one I fight for. But equally important it that my workflow will not work
safely, if it works with 2 svn trees. The chances that someone does a build
in /main with an not updated /extra (because he/she dont care) is too high,
and the consequences are down right frightening. If it happes, it might
change the translation templates, which again changes all language files,
which ultimately calls for translators to translate false texts. Is that
really wanted ?

3) There are absolutely no need to separate at svn/git level, but systems
have a .ignore facility so directory can be ignored and left empty (which
would be no problem for my workflow) so any developer not wanting the full
package, can still do a "svn co main" and limit to what is wanted. Btw I
dont need MAC development, why do I have to dowload that ?

4) When we walk about making the system modular, and want to separate e.g.
connectivity.po from /main/connectivity, we could use the same argument to
move all .src files away from main, in both cases we cannot generate a full
AOO installation. Actually modern modularity would call for the .src files
(and others) to contain the KID code, so  that en-US could be translated as
well. We assume that our developers speak perfect en-US, which I think is
far from the case (remember the ripples when a developer changes the en-US
strings, ALL languages have to be updated).

I will of course wait the 72 hours, but it seems to me that there are no
real consensus about integrating my proposed workflow (which NEEDS
integrated po files).

rgds
jan i.



>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>

Re: Question to all developers and translators: How integrated should translation be ?

Posted by Dick Groskamp <th...@quicknet.nl>.
Op 6-9-2013 14:30, janI schreef:
> Hi
>
> I am copying this mail to the l10n list, in order to involve the
> translators that do not follow dev@. But lets please keep the discussion on
> dev@.
>
> As its hopefully known, I have been working on a new workflow for the whole
> translation process for quite a long time.
>
> Now I have released the first major part of the workflow, my ultimate
> commit has lead to some valid concerns from Jürgen and Herbert, this is the
> second time (during development) that I hear the essentially same concern.
>
> Therefore we a a community need to decide which road we want to follow.
>
> The workflow I am developing, would in the final phase look like (without
> technical details).
>
> 1) at regular intervals en-US text are extracted from our source tree,
> transferred to pootle as templates, and all languages are updates with
> new/changed/deleted keys. This part is partly manual (starting the build,
> updating the languages).
>
> 2) Translators work on pootle, Translator-comitters update languages in svn
> from pootle and start an offline language-pack build.
>
> 3) Translators test their translation using the binary from our buildbot  +
> language pack (translators debug tool). Turnaround time < 1 day.
>
> 4) Buildbot automatically include changed translations on regular builds
> (e.g. weekly).
>
> The 2 concerns that have been raised are:
> 1) Letting committers do "svn commit" and "svn up" directly in pootle,
> might produce a build breaker for our buildbots. Suggestion let an admin do
> it e.g. once a week.
>
> my opinion: We do not need an admin in the loop, we dont have a controlling
> for developers and they are even more likely to produce build breakers.
> Remember a .po file build breaker will only affect the language in question
> and can be repaired just as fast.
>
> 2) Containing the .po files (translations) inside main/ cost 600Mb extra
> for en-US developers to download. Suggestion keep the .po file away from
> main in extras.
>
> my opion: Translator work is NOT "extra", its an essential needed part for
> our builds. In contrast to e.g. cliparts, the .po are part of the setup
> package (of course transformed, similar to a C++ source).
>
> My workflow can work, not as efficient with 1), but 2) breaks the workflow
> for technical reasons (think of someone extracting en-US strings from an
> updated /main to an old /extra and the published it to pootle == LOT of
> extra translation in all languages.
>
> I see translators working at the same level as developers, not as something
> /extras, and therefore the work should be treated as such.
>
> I have stopped work on further integration of genLang, until I either get
> lazy consensus on my workflow, or we decide to go for another workflow.
>
> thanks in advance for your comments (please all on dev@).
>
> rgds
> jan I.
>
In general I have no problem with this workflow and think
it might speed up things for the builders side of the proces.

The only problem I have is that I'm no techie and SVN is, to be honest,
to complicated for me.

Would it be possible, for instance after the deadline for translation 
has passed,
for a builder/developer/admin to update ALL languages from POOTLE?

I think with something like that we would have have ALL alterations into SVN
at once.
Mind you I have no idea how much work that would be, but it seems
to me it gives some assurance about the imported strings.

-- 
DiGro
___________________________
Apache OpenOffice 4.0.0 (Dutch) and scanned with Ziggo extended security (F-Secure)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org