Re: [libreoffice-l10n] Re: .src and .ui gettext migration

[Caolán McNamara]

On Wed, 2017-07-19 at 13:24 +0200, Leandro Regueiro wrote:
> Hi,
> changing the msgctxt is problematic from Pootle point of view since:
> 
> - Pootle will detect these as new strings that will be imported with
> no translation, and Pootle will mark old strings as obsolete.
> 
> Please hold, and work out a plan to push these strings to Pootle in
> order to avoid losing translations.

The original email has...
"
To try and minimize disruption I've a script available in master as
solenv/bin/update-for-gettext to update our current translations to
give them a new msgctxt (and update their keyid comment)
...
I've ... run this over the sample tarball of .pos extracted
from pootle that cloph provided. i.e.
python2 /path/solenv/bin/update-for-gettext translations/libo_ui
It shrinks and normalizes the msgctxt and updates the keyid comment for
.src and .ui strings and moves them into a per-module messages.po.

caolanm->cloph: will this script suffice for getting pootle updated ?
"

so that's what I hoping to do here, update the existing translations in
pootle that have the old autogeneratoed msgctxt to have the new
"static" msgctxt so that (most) translations are not considered
obsolete

-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

Re: [libreoffice-l10n] Re: .src and .ui gettext migration

[Leandro Regueiro]

On Sun, Jul 16, 2017 at 12:21 AM, Martin Srebotnjak  wrote:
> Caolan,
>
> you should test this really extensively, with the Pootle content as well as
> with the non-Pootle l10n teams.

Hi,
changing the msgctxt is problematic from Pootle point of view since:

- Pootle will detect these as new strings that will be imported with
no translation, and
- Pootle will mark old strings as obsolete.

Please hold, and work out a plan to push these strings to Pootle in
order to avoid losing translations. How many strings will be affected
by this change?


Thanks

> I can help you use the Slovenian translation, as I use a separate
> localization platform.
> Thus we could test if this change leads to translation corruption or loss
> of translated content.
>
> Lp, m.
>
> 2017-07-14 17:54 GMT+02:00 Caolán McNamara :
>
>> On Fri, 2017-07-14 at 15:57 +0200, Eike Rathke wrote:
>> > Questions:
>> > * where does the new implementation live that determines the actual
>> >   "resource" to be used for the current UI language, including
>> > possible language fallbacks?
>>
>> We pass GetUILanguageTag to boost, and that's always one of the
>> languages we translate to, as opposed to GetLanguageTag which could be
>> basically anything. So if someone's desktop locale is, say "de_AT",
>> then boost is just going to get "de_DE" from LibreOffice as the UI
>> language. boost itself in boost/libs/locale/src/shared/message.cpp (or
>> somewhere like that) will then try de_DE/module.mo and fallback to
>> de/module.mo
>>
>> > * does std::locale that replaces ResMgr and Translate::Create() that
>> >   uses boost::locale::generator with the new
>> >   LanguageTag::getGlibcLocaleString() fully handle BCP47?
>>
>> No, boost::gettext takes a posix locale string as its argument when it
>> builds a std::locale to use as input to the translate methods http://ww
>> w.boost.org/doc/libs/1_48_0/libs/locale/doc/html/rationale.html#why_pos
>> ix_names which is a bit sucky, but I updated liblangtag to handle the
>> only one of the locales we translate to (ca-valencia) which it didn't
>> already know how to map to a posix/glibc locale, so we should have a
>> valid posix/glibc locale string for each of the bcp-47 language tags
>> that identify a UI translation target
>>
>> --
>> To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
>> Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-
>> unsubscribe/
>> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
>> List archive: http://listarchives.libreoffice.org/global/l10n/
>> All messages sent to this list will be publicly archived and cannot be
>> deleted
>>
>
> --
> To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
> Problems? 
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/l10n/
> All messages sent to this list will be publicly archived and cannot be deleted

-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted

Re: [libreoffice-l10n] Re: .src and .ui gettext migration

[Martin Srebotnjak]

Caolan,

you should test this really extensively, with the Pootle content as well as
with the non-Pootle l10n teams.

I can help you use the Slovenian translation, as I use a separate
localization platform.
Thus we could test if this change leads to translation corruption or loss
of translated content.

Lp, m.

2017-07-14 17:54 GMT+02:00 Caolán McNamara :

> On Fri, 2017-07-14 at 15:57 +0200, Eike Rathke wrote:
> > Questions:
> > * where does the new implementation live that determines the actual
> >   "resource" to be used for the current UI language, including
> > possible language fallbacks?
>
> We pass GetUILanguageTag to boost, and that's always one of the
> languages we translate to, as opposed to GetLanguageTag which could be
> basically anything. So if someone's desktop locale is, say "de_AT",
> then boost is just going to get "de_DE" from LibreOffice as the UI
> language. boost itself in boost/libs/locale/src/shared/message.cpp (or
> somewhere like that) will then try de_DE/module.mo and fallback to
> de/module.mo
>
> > * does std::locale that replaces ResMgr and Translate::Create() that
> >   uses boost::locale::generator with the new
> >   LanguageTag::getGlibcLocaleString() fully handle BCP47?
>
> No, boost::gettext takes a posix locale string as its argument when it
> builds a std::locale to use as input to the translate methods http://ww
> w.boost.org/doc/libs/1_48_0/libs/locale/doc/html/rationale.html#why_pos
> ix_names which is a bit sucky, but I updated liblangtag to handle the
> only one of the locales we translate to (ca-valencia) which it didn't
> already know how to map to a posix/glibc locale, so we should have a
> valid posix/glibc locale string for each of the bcp-47 language tags
> that identify a UI translation target
>
> --
> To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
> Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-
> unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/l10n/
> All messages sent to this list will be publicly archived and cannot be
> deleted
>

-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted