key change suite windows installer

[tim_...@planet.nl]

Hi

there has been some changes in the installer files of the semonkey windows installer whitout changing the label see:

http://hg.mozilla.org/comm-central/rev/4daac073741d

greetings

MM

[Robert Strong]

The strings that were changed should be caught by the check-locales.pl
script even without changing the property names.
http://hg.mozilla.org/comm-central/diff/4daac073741d/suite/locales/Makefile.in

Robert

> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
>

[Mad Maks]

Robert Strong wrote:
> The strings that were changed should be caught by the check-locales.pl
> script even without changing the property names.
> http://hg.mozilla.org/comm-central/diff/4daac073741d/suite/locales/Makefile.in
>
>

Do you mean that we don't have to change ${BrandShortName} into
$BrandShortName?

The l10n dashboard does not list changes without changing the entity
label. If it has to be changed in de l10n files is it imported to make a
announcement in the newsgroup otherwise a lot of teams will miss it.

Greetings

MM

[Axel Hecht]

The target goal is to have build failures show up on the dashboard, but
that's a bit out.

Axel

[Ehsan Akhgari]

On Mon, Dec 22, 2008 at 5:04 PM, Axel Hecht <l1...@mozilla.com> wrote:
>> Do you mean that we don't have to change ${BrandShortName} into
>> $BrandShortName?
>>
>> The l10n dashboard does not list changes without changing the entity
>> label. If it has to be changed in de l10n files is it imported to make a
>> announcement in the newsgroup otherwise a lot of teams will miss it.
>>
>
> The target goal is to have build failures show up on the dashboard, but
> that's a bit out.

I've had this idea for a while: how about having a mechanism which
detects the discrepancies in embedded variables in original and
translated strings? For example, if the source string is "Install a
new version of %S", and the translation is "نصب نسخه‌ای جدید"
(omitting the %S), then something's probably wrong with the
translation, and it should turn the locale's tinderbox red.

Narro has this feature built-in, and it's really helpful. These
discrepancies can be reported as warnings if there are cases where
such omissions are elaborate and should not be counted as errors.

--
Ehsan
<http://ehsanakhgari.org/>

[Anas Husseini]

Not so practical. There are cases where %S are omitted in purpose (in case
where %S is a particular number in Arabic). Thus, it'll lead to other
problems.

I'd suggest instead to implement a detector of ${BrandShortName} and such
variables.

Regards

- Anas

On Mon, Dec 22, 2008 at 4:28 PM, Ehsan Akhgari <ehsan....@gmail.com>wrote:

> I've had this idea for a while: how about having a mechanism which
> detects the discrepancies in embedded variables in original and
> translated strings? For example, if the source string is "Install a
> new version of %S", and the translation is "نصب نسخه‌ای جدید"
> (omitting the %S), then something's probably wrong with the
> translation, and it should turn the locale's tinderbox red.

> --
> Ehsan
> <http://ehsanakhgari.org/>
>

--
Experience is something you don't get until just after you need it.

[Frank Wein]

Mad Maks wrote:
> Robert Strong wrote:
>> The strings that were changed should be caught by the check-locales.pl
>> script even without changing the property names.
>> http://hg.mozilla.org/comm-central/diff/4daac073741d/suite/locales/Makefile.in
>>
>>
>
> Do you mean that we don't have to change ${BrandShortName} into
> $BrandShortName?

Just in case it is not clear: The strings need to be changed, otherwise
the l10n build will not succeed as check-locales.pl will complain. This
change was necessary to support rebranding of the installer.

Frank