1242542 - [pl][2.0] Sign-off for Polish l10n of Firefox for iOS v2.0

Status: RESOLVED FIXED

(Mozilla Localizations :: pl / Polish, defect)

Description

[Jeff Beatty [:gueroJeff]]

This bug is for signing off on your localization for shipping it in Firefox for iOS v2.0. Please close this bug as RESOLVED FIXED by 1 February if you are comfortable with your localization work shipping in Firefox for iOS v2.0.

Comment 1

[Stefan Plewako [:stef]]

Who is responsible for Firefox for iOS Firefox localizability bugs?

Comment 2

[Jeff Beatty [:gueroJeff]]

Stefan and the iOS team.

It should be noted that, just as with 1.1, internationalization (or localizability) bugs are not dependencies of a l10n community's sign off. This sign off is asking if the Polish team has completed localization (including translation and testing of available strings) to the best of their ability and recommends shipping their contributions, regardless of what i18n bugs exist in the product.

Comment 3

[Stefan Plewako [:stef]]

Please note that ignoring reported bugs lowers app quality, demotivates testers and is generally bad.

What's more, while l10n drivers suggest that internationalization (or localizability) bugs are not dependencies of a l10n sign off, those bugs in fact have impact on it (like inability to test bug 1235840).

Ignoring that could potentially lead to the conclusion that to the best of our inability to test things we are supposed recommend to ship (and other aspects) we will be in fact unable to sing-off.

With above in mind, similarly as in bug 1212574, please include Polish in this release.

Comment 4

[Jeff Beatty [:gueroJeff]]

(In reply to Stefan Plewako [:stef] from comment #3)
> Please note that ignoring reported bugs lowers app quality, demotivates
> testers and is generally bad.
> 
> What's more, while l10n drivers suggest that internationalization (or
> localizability) bugs are not dependencies of a l10n sign off, those bugs in
> fact have impact on it (like inability to test bug 1235840).
> 
> Ignoring that could potentially lead to the conclusion that to the best of
> our inability to test things we are supposed recommend to ship (and other
> aspects) we will be in fact unable to sing-off.
> 
> With above in mind, similarly as in bug 1212574, please include Polish in
> this release.

Thank you for signing off. Allow to try to address your concerns:

1) "Ignoring" is a charged word. These have not been intentionally set aside, in fact, they haven't been triaged even because they hadn't arrived on the iOS team's radar. Please avoid using charged language to make your points, as they will be better received.
2) i18n bugs are dependencies of l10n in the same way that feature dev is a dependency of l10n: we don't sign off on feature development because it's outside of our scope. Project management allows each stakeholder to hold their own spheres of stewardship within a project. The stewardship of the l10n community is around their own contributions toward shipping a localization (in this case, the translation of strings, testing those translations, and reporting both l10n and i18n bugs). The stewardship of the dev team is around their own contributions toward shipping a product that can be localized (in this case, resolving the i18n bugs you have filed). If i18n has issues addressed, it is up to the dev team to resolve and sign off on them independently of the l10n community's contributions. 

I've spoken with Stefan and we will find a way to better expose these i18n bugs to the team to traige and address them. He's confident that they can be addressed this week.

Comment 5

[Stefan Plewako [:stef]]

(In reply to Jeff Beatty [:gueroJeff] from comment #4)
> 1) "Ignoring" is a charged word. These have not been intentionally set
> aside, in fact, they haven't been triaged even because they hadn't arrived
> on the iOS team's radar. Please avoid using charged language to make your
> points, as they will be better received.

You seem to suggest that reporting a bug (in the correct component) on bmo is not enough to get it on the responsible teams radar in like six months. That is supposed to prove that these have not been intentionally set aside, left untriaged and that I shouldn't use word "ignoring". Hard to agree with that…

> 2) i18n bugs are dependencies of l10n in the same way that feature dev is a
> dependency of l10n: we don't sign off on feature development because it's
> outside of our scope. Project management allows each stakeholder to hold
> their own spheres of stewardship within a project. The stewardship of the
> l10n community is around their own contributions toward shipping a
> localization (in this case, the translation of strings, testing those
> translations, and reporting both l10n and i18n bugs). The stewardship of the
> dev team is around their own contributions toward shipping a product that
> can be localized (in this case, resolving the i18n bugs you have filed). If
> i18n has issues addressed, it is up to the dev team to resolve and sign off
> on them independently of the l10n community's contributions. 

You seem to suggest that in general there are no overlaps and dependencies between teams, stakeholders and areas. That is not true.

> I've spoken with Stefan and we will find a way to better expose these i18n
> bugs to the team to traige and address them. He's confident that they can be
> addressed this week.

In bug 1212574 comment 5 I see similarly sounding "We can raise flags about these localizability bugs to the iOS team and get some understanding of when they can address and resolve them, in the mean time." with almost no detectable effect. Hopefully, this time the outcome would be better.

Comment 6

[Jeff Beatty [:gueroJeff]]

Stef, according to https://l10n.mozilla-community.org/~flod/webstatus/views/product_diff.php?product=firefox-ios&locale=pl there are still 5 strings missing. Could you please translate those before Monday?

Thanks,
Jeff

Comment 7

[Stefan Plewako [:stef]]

https://github.com/mozilla-l10n/firefoxios-l10n/commit/85eef52872811b743e833d36c38eef961ca54326
https://github.com/mozilla-l10n/firefoxios-l10n/commit/27db195197043d5e126c74058232850f3ce93787

I have temporarily reverted two changes that by some logic are not meant to be included, webstatus should be happy by now.

I would be also interested to learn about that logic/branching process. For reference, reverted changes were made for:
1. https://github.com/splewako/firefox-ios-l10n-en/commit/79387663e36479fed3003ffa5069802b5912fa13
   https://github.com/mozilla/firefox-ios/commit/55332ba09e1fbd4b49386171eb2381190808c59f
2. https://github.com/splewako/firefox-ios-l10n-en/commit/1d6dd757b5aaf162590cbbcd39d318313cbc1c60
   https://github.com/mozilla/firefox-ios/commit/e63cf3bf645820271291e1e53d4b1119587fe9f5
Check https://github.com/splewako/firefox-ios-l10n-en/commits to see more.

I simply didn't notice anything indicating that these strings will not be included in 2.0 (apart from en-US and templates l10n repository folders not updated since Dec 31, 2015)

Comment 8

[Jeff Beatty [:gueroJeff]]

As you've noted, the differences are largely due to what you're translating. The string freeze en-US & templates export contain the strings that have been flagged as being included in the next version, whereas you're tranlating the master branch, which contains no string filtering for versions.

Comment 9

[Stefan Plewako [:stef]]

Right, where can I learn about that flagging process and how can I track it?