On 4/5/13 10:21 AM, janI wrote:
> On 5 April 2013 09:16, Jürgen Schmidt <jogischm...@gmail.com> wrote:
> 
>> On 4/4/13 9:22 PM, janI wrote:
>>> On 4 April 2013 20:58, Rob Weir <robw...@apache.org> wrote:
>>>
>>>> On Thu, Apr 4, 2013 at 11:21 AM, janI <j...@apache.org> wrote:
>>>>
>>>>> Hi.
>>>>>
>>>>> Since we are now putting a lot of positive energy into 4.0, we have a
>> lot
>>>>> of changes in trunk and at the same time I have made language changes
>> in
>>>>> the l10n branch. This is a bad combination, that gives me quite some
>>>> extra
>>>>> manual work. Furthermore I would like the 4.0 language files to be
>> clean
>>>>> (whether we make them as po for sdf).
>>>>>
>>>>> If there are no objections I will merge the language changes (NO code
>>>>> changes) back into trunk.
>>>>>
>>>>> The changes in trunk will primarely be in .src files, where language
>>>>> different from en-US, as discussed in an earlier thread. This will not
>> in
>>>>> any way affect the modules or the build system. All changes are
>> committed
>>>>> in l10n branch.
>>>>>
>>>>> If no objections I will merge into trunk, monday april 8 using lazy
>>>>> consensus.
>>>>>
>>>>>
>>>> So we had translations in Pootle, in the 3.4 branch and in the trunk.  I
>>>> assume you're able to get us all back together?  If so, this is a big
>> step
>>>> forward.  Thanks!
>>>>
>>>
>>> Yes if you look in branches/l10n/solenv/lang you will find a consolidated
>>> set of po files (which cannot be used for 4.0, before I get genLang
>>> integrated in build)
>>
>> I don't think that solenv is the best place for hosting the po files.
>> Can you explain why you have chosen solenv?
>>
> I chose solenv, because it is the place we store build information, but it
> can also be l10ntools that might be better (and is easy to change).

solenv = solar build env, contains of course a lot of things for the
build env but no data lile po files

> 
> I do not like languages as extras, that is the wrong signal to send,
> languages are an integrated part of aoo and not an addon. We have
> "extensions" and "swext" in main, they should go long before our languages.

I don't see and never have seen it this way. The idea of keeping the
translation data files separately is simply to reduce the stuff for
daily development work I believe.

Languages are of course no addon and a very important part but we used
en-SU as our reference language and start normally with it during the
development. The translation come in later in the development cycle and
requires the collaboration with our translators.

And it much faster to build with out lang when do your daily work as
developer. If translation issues have to fixed or if translation have to
check then of course  we build with lang.

But for developers it should be configurable to simplify the daily work
form my pov.


> 
> Developers should always try their work with languages, actually I have the
> opinion that we should always build with languages (or at least compile).

I agree i general and lang tests should be part of the normal work but
not at every time.

If you work on bug fixes you are fine with an en-US version. We don't
give en-US really a preference but we have to use one source reference
language and that is en-US, not more and not less. For the release all
supported supported languages are important and equal.

> 
> Just to be sure, I will not move the lang directory to trunk now...it is
> not part of this lazy con. decision.

Let us simply find a better place for these files where of course it is
easier to find them. I would have never searched under solenv.

Juergen


> 
> rgds
> Jan I
> 
> 
>>
>> solenv is typically the home of our build env in the broader sense. We
>> had reasons to extract the localization files and moved it in
>> extras/l10n. One reason was to reduce the files needed for daily
>> development without building localized builds.
>>
>> Juergen
>>
>>>
>>> A message with a non en-US languages  in the source code "overrule" a
>> real
>>> translation (comming from pootle or elsewhere) of that message (by simple
>>> order of presence).
>>>
>>> These messages are wrong, and the new genLang does not allow them.
>>>
>>> rgds
>>> jan I
>>>
>>>
>>>
>>>
>>>>
>>>> -Rob
>>>>
>>>>
>>>>
>>>>> rgds
>>>>> Jan I.
>>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>
> 


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

Reply via email to