Fwd: [iOS] String freeze this week

Stefan Arentz

unread,

Jun 30, 2015, 10:58:41 PM6/30/15

to dev-l10n

---------- Forwarded message ----------
From: Stefan Arentz <sar...@mozilla.com>
Date: Tue, Jun 30, 2015 at 10:53 PM
Subject: [iOS] String freeze this week
To: mobile-firefox-dev <mobile-fi...@mozilla.org>

As discussed last week in Whistler, we are aiming for L10N string freeze by
the end of this week.

I have browsed through the app sources and I could not find any static
(non-NSLocalizedString) strings. Please prove me wrong.

We do have a bunch of strings that need a quick review before they can be
localized in their final form:

https://bugzilla.mozilla.org/showdependencytree.cgi?id=1168395&hide_resolved=1

I'll hope to get those finalized on Thursday.

My questions to you are:

* If you know we are going to add new functionality with new strings in the
coming days/week, please add them as soon as possible. Or discuss so that
we can find a way to get them translated before the code lands.

* If you know of more strings in the app that need review, please file a
bug and make it block 1168395.

What did I miss?

S.

droid...@gmail.com

unread,

Jul 1, 2015, 3:13:56 AM7/1/15

to

https://bugzilla.mozilla.org/show_bug.cgi?id=1168395#c2
Here is for Swedish

Stef

unread,

Jul 1, 2015, 6:36:56 AM7/1/15

to dev-l10n

> Wiadomość napisana przez Stefan Arentz <sar...@mozilla.com> w dniu 1 lip 2015, o godz. 04:58:
>
> What did I miss?

https://bugzilla.mozilla.org/showdependencytree.cgi?id=1092387&maxdepth=1&hide_resolved=1 maybe?

Stefan Arentz

unread,

Jul 2, 2015, 11:34:44 AM7/2/15

to Luna Jernberg, dev-l10n

The strings in settings are all localized in the code now. If they did not
show up in the last string export then they will for sure tomorrow.

The pop-up one should have been in Build 22 actually. Did it not export
correctly?

S.

On Wed, Jul 1, 2015 at 3:13 AM, <droid...@gmail.com> wrote:

> https://bugzilla.mozilla.org/show_bug.cgi?id=1168395#c2
> Here is for Swedish

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

Stefan Arentz

unread,

Jul 2, 2015, 11:35:39 AM7/2/15

to Stef, dev-l10n

Excellent. I will do going over all those bugs too. Silly of me to not find
those :-/

S.

Stefan Arentz

unread,

Jul 2, 2015, 3:52:55 PM7/2/15

to mobile-firefox-dev, dev-l10n

I think we are pretty close. I don't think we have any outstanding strings
at this point.

I have looked at many l10n bugs and resolved almost all of them.

L10N related commits/changes:

Fixes 1163117 - Copy for on-boarding
<https://github.com/mozilla/firefox-ios/commit/cef4c9d6425d5371092fbeb95156c831009a7d72>

Fixes 1172111 - Copy for remote tabs panel
<https://github.com/mozilla/firefox-ios/commit/f428f44068300c3548195c9ae63432fe3c0505fd>

Fixes 1168402 - Copy for Reading List empty-state
<https://github.com/mozilla/firefox-ios/commit/70761d5711e43507dd787df8d5a6a659a5a0d55f>

Fixes 1168400 - Copy for Send Tab extension empty state
<https://github.com/mozilla/firefox-ios/commit/77bb893481ff28b8aeae2e3d946c11336aede32f>

Fixes 1151995 - [l10n] Fix string consistency: "Tap to reload page"
<https://github.com/mozilla/firefox-ios/commit/0144f25f83061bdb8ce417c873fb9ee88582224b>

Fixes 1153333 - Missing notes for NSLocalizedString
<https://github.com/mozilla/firefox-ios/commit/ad8108e68f367adbfbf911278c624c3dc90c276b>

Fixes 1163151 - Firefox for iOS: verify usage of newslines in strings
<https://github.com/mozilla/firefox-ios/commit/0f491a644b4b32a52ea170d1137b93caefe312dc>

Fixes 1179863 - Copy for Send Tab not logged in state
<https://github.com/mozilla/firefox-ios/commit/503894866f877d0155034797ee56cf20bf933ef2>

Fixes 1175887 - Not all string tables are properly converted to .stri…
<https://github.com/mozilla/firefox-ios/commit/6e7d3ee3567ad3b3fbcf29e07c267ec48ef54731>

The last one is worth mentioning: a number of strings were not actually
included in the build. I'm surprised nobody really noticed. I think that
shows that we need to figure out a way to do more automated testing. For
example with screenshots taken of every possible piece of UI that we have.

S.

Francesco Lodolo [:flod]

unread,

Jul 2, 2015, 4:05:27 PM7/2/15

to Stefan Arentz, dev-l10n, mobile-firefox-dev

Hi Stefan,
to answer your question "I'm surprised nobody really noticed.", it goes
back to the discussion we had in Whistler: so far l10n builds have been
useful up to a certain point.

I have extra strings localized in Italian, but they're ignored because the
English reference file doesn't have them. Therefore I can't safely report
bugs for missing translations.

Locales working on Pootle are not updated automatically (yet). Again, a
missing string in the device might be due to Pootle being behind with the
export.

Luckily Test Flight builds will get a lot more useful starting from this
Friday, with strings stabilizing and a clearer process for string exports
and SVN updates.

Francesco

> _______________________________________________
> mobile-firefox-dev mailing list
> mobile-fi...@mozilla.org
> https://mail.mozilla.org/listinfo/mobile-firefox-dev
>
>

Stef

unread,

Jul 2, 2015, 4:47:55 PM7/2/15

to dev-l10n, mobile-firefox-dev

> Wiadomość napisana przez Stefan Arentz <sar...@mozilla.com> w dniu 2 lip 2015, o godz. 21:52:

>
> I think we are pretty close. I don't think we have any outstanding strings
> at this point.
>
> I have looked at many l10n bugs and resolved almost all of them.

Nice!

> Fixes 1175887 - Not all string tables are properly converted to .stri…
> <https://github.com/mozilla/firefox-ios/commit/6e7d3ee3567ad3b3fbcf29e07c267ec48ef54731>
>
>
> The last one is worth mentioning: a number of strings were not actually
> included in the build. I'm surprised nobody really noticed. I think that
> shows that we need to figure out a way to do more automated testing. For
> example with screenshots taken of every possible piece of UI that we have.

Screenshots of every possible UI state (in language other then English, pseudolocale maybe?) would be great but that could be quite hard and I think improving l10n story could yield better results.

Most of the strings should be localized in pl¹ but import/export and ignoring valid strings especially sucks and irregular test builds suck too - how many unlocalizable unreported strings can be spotted in last TestFlight build (22? from ~2 weeks ago?)?

1. Thanks to https://github.com/splewako/firefox-ios-l10n-en

Stefan Arentz

unread,

Jul 2, 2015, 9:07:09 PM7/2/15

to Francesco Lodolo [:flod], dev-l10n, mobile-firefox-dev

To be clear, I did not intend to blame the L10N community in any kind of
way. We are extremely happy and impressed with the L10N help for this
project and everyone has been doing an absolute great job dealing with this
project. You all rock. I am not joking.

If there is anyone to blame then it is me messing up those scripts and not
including all the strings in the builds.

I think one of the problems of our current Test Flight program is that our
test audience is not diverse enough. It would be ideal if we we have 4 or 5
people testing in each supported locale. But we don't. I think we currently
have a small subset of the L10N people and then next to that mostly english
and german testers. So that is not optimal. For the (internal) Aurora
builds this is even worse I think.

I'm sure we can find more testers but I don't know how to fix this in the
short term.

S.

On Thu, Jul 2, 2015 at 4:05 PM, Francesco Lodolo [:flod] <fl...@lodolo.net>
wrote:

> Hi Stefan,
> to answer your question "I'm surprised nobody really noticed.", it goes
> back to the discussion we had in Whistler: so far l10n builds have been
> useful up to a certain point.
>
> I have extra strings localized in Italian, but they're ignored because the
> English reference file doesn't have them. Therefore I can't safely report
> bugs for missing translations.
>
> Locales working on Pootle are not updated automatically (yet). Again, a
> missing string in the device might be due to Pootle being behind with the
> export.
>
> Luckily Test Flight builds will get a lot more useful starting from this
> Friday, with strings stabilizing and a clearer process for string exports
> and SVN updates.
>
> Francesco
>
>
> 2015-07-02 21:52 GMT+02:00 Stefan Arentz <sar...@mozilla.com>:
>

>> I think we are pretty close. I don't think we have any outstanding
>> strings at this point.
>>
>> I have looked at many l10n bugs and resolved almost all of them.
>>

>> Fixes 1175887 - Not all string tables are properly converted to .stri…
>> <https://github.com/mozilla/firefox-ios/commit/6e7d3ee3567ad3b3fbcf29e07c267ec48ef54731>
>>
>>
>> The last one is worth mentioning: a number of strings were not actually
>> included in the build. I'm surprised nobody really noticed. I think that
>> shows that we need to figure out a way to do more automated testing. For
>> example with screenshots taken of every possible piece of UI that we have.
>>

Francesco Lodolo [:flod]

unread,

Jul 3, 2015, 3:15:27 AM7/3/15

to Stefan Arentz, dev-l10n, mobile-firefox-dev

I don't think we felt blamed (I definitely didn't), and the support for
l10n has been great, especially in terms of responses and support :-)

We have pain points on both sides (e.g. you have nothing to do with the
Pootle issue) and we're fixing holes in the road as we go. From my point
of view it's inevitable for a v1, and so far it's going even better than
I expected.

The was merely an explanation for the scarcity of l10n bugs so far,
things will change from next week.

Francesco

> <mailto:sar...@mozilla.com>>:

> <mailto:mobile-fi...@mozilla.org>
> https://mail.mozilla.org/listinfo/mobile-firefox-dev
>
>
>

Brian Nicholson

unread,

Jul 7, 2015, 4:34:31 PM7/7/15

to Stef, dev-l10n, mobile-firefox-dev

Can someone summarize where we are now with the string freeze, and
what the freeze covers?

Namely, are a11y strings included in the freeze? If so, I think our
a11y strings are far from complete -- we continue to get PRs from
dusek (our awesome a11y contributor) that contain NSLocalizedString
additions. Also, I expect that we'll be adding/updating a11y labels as
we continue to refine our UI tests since KIF and a11y strings are
tightly coupled.

On Thu, Jul 2, 2015 at 1:47 PM, Stef <sple...@aviary.pl> wrote:
>> Wiadomość napisana przez Stefan Arentz <sar...@mozilla.com> w dniu 2 lip 2015, o godz. 21:52:
>>

>> I think we are pretty close. I don't think we have any outstanding strings
>> at this point.
>>
>> I have looked at many l10n bugs and resolved almost all of them.
>

> Nice!

>
>> Fixes 1175887 - Not all string tables are properly converted to .stri…
>> <https://github.com/mozilla/firefox-ios/commit/6e7d3ee3567ad3b3fbcf29e07c267ec48ef54731>
>>
>>
>> The last one is worth mentioning: a number of strings were not actually
>> included in the build. I'm surprised nobody really noticed. I think that
>> shows that we need to figure out a way to do more automated testing. For
>> example with screenshots taken of every possible piece of UI that we have.
>

> Screenshots of every possible UI state (in language other then English, pseudolocale maybe?) would be great but that could be quite hard and I think improving l10n story could yield better results.
>
> Most of the strings should be localized in pl¹ but import/export and ignoring valid strings especially sucks and irregular test builds suck too - how many unlocalizable unreported strings can be spotted in last TestFlight build (22? from ~2 weeks ago?)?
>
>
> 1. Thanks to https://github.com/splewako/firefox-ios-l10n-en

> _______________________________________________
> mobile-firefox-dev mailing list
> mobile-fi...@mozilla.org

> https://mail.mozilla.org/listinfo/mobile-firefox-dev

Axel Hecht

unread,

Jul 7, 2015, 6:30:12 PM7/7/15

to Brian Nicholson, mobile-firefox-dev

Any strings should be frozen, including a11y.

If that's not the case, that's bad.

The resolution to that is either to get a timeline for a11y in the v1
release, or to remove it from the v1 release.

Note, I'm not sure that a mixed language a11y story is a good user
experience, so if we can't get a localized a11y UX into v1, we'd need to
find a way to disable it.

Axel

Stefan Arentz

unread,

Jul 8, 2015, 10:03:42 AM7/8/15

to Brian Nicholson, dev-l10n, mobile-firefox-dev

On Tue, Jul 7, 2015 at 4:34 PM, Brian Nicholson <bnich...@mozilla.com>

wrote:

> Can someone summarize where we are now with the string freeze, and
> what the freeze covers?
>

I think we are pretty much string complete for non-a11ly strings.

The export that I did yesterday included the last extra feature that was in
flight, the View Later action extension.

If anyone is aware of other functionality that needs to land, this is the
time to let us know.

>
> Namely, are a11y strings included in the freeze? If so, I think our
> a11y strings are far from complete -- we continue to get PRs from
> dusek (our awesome a11y contributor) that contain NSLocalizedString
> additions.

So I did not take a11y into account. Well, I sort of did, but as you are
saying more patches are coming in. I kind of assumed that 'we will take
whatever we can get'. But if that does not work with a11y then maybe we
need to land those patches later so that we can land them fully localized?
We can always do small incremental updates after our v1 with a11y
improvements.

> Also, I expect that we'll be adding/updating a11y labels as
> we continue to refine our UI tests since KIF and a11y strings are
> tightly coupled.
>

Emily ran into an issue where labels are sometimes unpredictable. Like when
they are dynamic. I wonder if we should start using accessibility
identifiers more consistently instead. AFAIK those are not end-user facing
and can be used to pinpoint specific elements without relying on strings or
localized strings. What do you think?

S.

Stef

unread,

Jul 8, 2015, 10:21:44 AM7/8/15

to Stefan Arentz, dev-l10n, Brian Nicholson, mobile-firefox-dev

> Wiadomość napisana przez Stefan Arentz <sar...@mozilla.com> w dniu 8 lip 2015, o godz. 16:03:

>
> On Tue, Jul 7, 2015 at 4:34 PM, Brian Nicholson <bnich...@mozilla.com <mailto:bnich...@mozilla.com>> wrote:
> Can someone summarize where we are now with the string freeze, and
> what the freeze covers?
>
> I think we are pretty much string complete for non-a11ly strings.

I think string freeze Firefox for iOS is mistake (esp. for 1.0) - don't get me wrong, the idea in general sounds great until you get to Firefox desktop like ugliness and problems. IMO it would be better to focus on quality and polishing features then trying to attract less responsive l10n teams, simply don't try to hard to keep the freeze.

stef

Jeff Beatty

unread,

Jul 8, 2015, 10:43:39 AM7/8/15

to Stef, dev-l10n

String freeze is an important milestone within the end game of an
international product's release cycle. It shouldn't be ignored or
skipped, but accounted for within the considerations of the development
team's needs. It's possible to both string freeze and focus on quality &
feature polish.

There's still some debate about when this string freeze will take place.
We'll be in touch as that discussion progresses.

El 7/8/15 a las 8:21 AM, Stef escibió:

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

--
*Jeff Beatty*
Localization Engineer
@mozilla_l10n <http://twitter.com/mozilla_l10n>
801.367.3763

Stefan Arentz

unread,

Jul 8, 2015, 10:50:44 AM7/8/15

to Stef, dev-l10n, Brian Nicholson, mobile-firefox-dev

I'm happy to call it a soft-freeze if others agree.

We are very close being frozen but I have no doubts that small tweaks to
strings will happen. I would be very happy if we can deal with that.

S.

On Wed, Jul 8, 2015 at 10:21 AM, Stef <sple...@aviary.pl> wrote:

> Wiadomość napisana przez Stefan Arentz <sar...@mozilla.com> w dniu 8 lip
> 2015, o godz. 16:03:
>
> On Tue, Jul 7, 2015 at 4:34 PM, Brian Nicholson <bnich...@mozilla.com>

Stef

unread,

Jul 8, 2015, 11:04:42 AM7/8/15

to Jeff Beatty, dev-l10n

> Wiadomość napisana przez Jeff Beatty <jbe...@mozilla.com> w dniu 8 lip 2015, o godz. 16:43:

>
> String freeze is an important milestone within the end game of an international product's release cycle. It shouldn't be ignored or skipped, but accounted for within the considerations of the development team's needs. It's possible to both string freeze and focus on quality & feature polish.

Maybe in an ideal world… in Mozilla it hurts localizability.

Jeff Beatty

unread,

Jul 8, 2015, 11:13:00 AM7/8/15

to Stef, dev-l10n

At some point, every product has to experience a string freeze
milestone, just as it has to experience a feature complete milestone.
Otherwise, the products don't ship and remain in a constant state of
development.

I don't imply we're perfect at it, but the ideal is what we need to
strive for rather than settle for the status quo.

El 7/8/15 a las 9:04 AM, Stef escibió:

>> Wiadomość napisana przez Jeff Beatty <jbe...@mozilla.com> w dniu 8 lip 2015, o godz. 16:43:
>>
>> String freeze is an important milestone within the end game of an international product's release cycle. It shouldn't be ignored or skipped, but accounted for within the considerations of the development team's needs. It's possible to both string freeze and focus on quality & feature polish.
> Maybe in an ideal world… in Mozilla it hurts localizability.

Brian Nicholson

unread,

Jul 8, 2015, 12:03:13 PM7/8/15

to Stefan Arentz, dev-l10n, mobile-firefox-dev

On Wed, Jul 8, 2015 at 7:03 AM, Stefan Arentz <sar...@mozilla.com> wrote:
> So I did not take a11y into account. Well, I sort of did, but as you are
> saying more patches are coming in. I kind of assumed that 'we will take
> whatever we can get'. But if that does not work with a11y then maybe we need
> to land those patches later so that we can land them fully localized? We can
> always do small incremental updates after our v1 with a11y improvements.

I imagine a "we will take what we can get" approach will be fine with
a11y (i.e., dusek), since I think where we're at right now is in
pretty good shape. As long as he's aware of the freeze and doesn't get
cut off without warning, we should be OK. Sounds like the next batch
of PRs should address any remaining a11y strings that are needed [1].

> Emily ran into an issue where labels are sometimes unpredictable. Like when
> they are dynamic. I wonder if we should start using accessibility
> identifiers more consistently instead. AFAIK those are not end-user facing
> and can be used to pinpoint specific elements without relying on strings or
> localized strings. What do you think?

I'm not sure what you mean by labels being unpredictable. They're
dynamic, as you said, since they change based on the text content and
app state, but the label should always be deterministic based on a
given sequence of actions. If not, that seems like a bug.

A similar discussion of accessibility IDs vs labels came up in KIF
discussions. One of the KIF owners discourages using identifiers since
KIF is supposed to be used from the user's perspective, so user-facing
strings (labels) are preferable to magic developer strings
(identifiers) [2]. I tend to agree with him, though there are some
cases mentioned in that thread where identifiers could be useful.

That said, if we're writing new tests and we need label changes, but
we're string frozen, accessibility identifiers seem like a good
fallback so that we aren't blocked. If we do that, we'll probably want
to make a note to ourselves to switch from IDs -> labels after we ship
in those situations.

[1] https://github.com/mozilla/firefox-ios/issues/683#issuecomment-119566048
[2] https://github.com/kif-framework/KIF/issues/243#issuecomment-23363722

Brian Nicholson

unread,

Jul 8, 2015, 12:14:28 PM7/8/15

to Stefan Arentz, dev-l10n, mobile-firefox-dev

On Wed, Jul 8, 2015 at 7:50 AM, Stefan Arentz <sar...@mozilla.com> wrote:
> I'm happy to call it a soft-freeze if others agree.
>
> We are very close being frozen but I have no doubts that small tweaks to
> strings will happen. I would be very happy if we can deal with that.
>
> S.

Back when we were originally planning to ship v1, I remember talking
about a "feature freeze" period before shipping where we would not
accept any new features, but focus only on UI polish and fixing
existing bugs in the product. Hopefully we're still planning on
something similar this time? If so, that might be a good time to
simultaneously declare "string freeze" since no new features should,
theoretically, mean no new strings in the product (assuming we're
happy with the ones we have).

Without a feature freeze, I don't think we can reasonable expect to
keep strings frozen. To name a few, bug 1109684, bug 1109684, and bug
1172054 are all incoming tracking+ features that will require new
strings.

Karen Rudnitski

unread,

Jul 8, 2015, 12:17:06 PM7/8/15

to Brian Nicholson, Stefan Arentz, Chaulk, Jennifer, dev-l10n, mobile-firefox-dev

Adding Jenn

Stef

unread,

Jul 8, 2015, 3:02:16 PM7/8/15

to dev-l10n

> Wiadomość napisana przez Jeff Beatty <jbe...@mozilla.com> w dniu 8 lip 2015, o godz. 17:12:

>
> At some point, every product has to experience a string freeze milestone, just as it has to experience a feature complete milestone. Otherwise, the products don't ship and remain in a constant state of development.

No, at least not in reality and for sure not in Mozilla even if for some, that would be more or less true.

> I don't imply we're perfect at it, but the ideal is what we need to strive for rather than settle for the status quo.

String freeze concept from good practice and addition to stabilization period has been transformed to counterproductive joke about itself, in huge part at the expense of l10n teams and areas of their responsibility.

I think I see efforts to protect status quo and not push for improvement but I'm just localizer and for sure don't know everything.

Axel Hecht

unread,

Jul 9, 2015, 6:50:03 AM7/9/15

to

Stef, it doesn't really matter what you want here. Sorry, but you're just distracting people that are trying to get this shipping.

Axel

Stefan Arentz

unread,

Jul 9, 2015, 7:46:36 PM7/9/15

to Martin Jernberg, dev-l10n, Brian Nicholson, mobile-firefox-dev

Hi Martin, the strings you mention, the quickstart, should be in the last
export. Do they not show up in Pootle for you?

Can you be more specific about the menu items? If we missed something then
I'd like to open a bug for it.

S.

On Thu, Jul 9, 2015 at 6:29 PM, Martin Jernberg <Martin....@tibble.nu>
wrote:

> Will continue to translate after the freeze any date when its over and we
> can start to translate for build 23, also strings for the quickstart guide
> and some menu items need to be added into Pootle for Swedish L10n
> ________________________________________
> From: mobile-firefox-dev [mobile-firefo...@mozilla.org] On
> Behalf Of Stefan Arentz [sar...@mozilla.com]
> Sent: 08 July 2015 16:03
> To: Brian Nicholson

> Cc: dev-l10n; mobile-firefox-dev
> Subject: Re: [iOS] String freeze this week
>

> On Tue, Jul 7, 2015 at 4:34 PM, Brian Nicholson <bnich...@mozilla.com
> <mailto:bnich...@mozilla.com>> wrote:
> Can someone summarize where we are now with the string freeze, and
> what the freeze covers?
>
> I think we are pretty much string complete for non-a11ly strings.
>

> The export that I did yesterday included the last extra feature that was
> in flight, the View Later action extension.
>
> If anyone is aware of other functionality that needs to land, this is the
> time to let us know.
>
>
> Namely, are a11y strings included in the freeze? If so, I think our
> a11y strings are far from complete -- we continue to get PRs from
> dusek (our awesome a11y contributor) that contain NSLocalizedString
> additions.
>

> So I did not take a11y into account. Well, I sort of did, but as you are
> saying more patches are coming in. I kind of assumed that 'we will take
> whatever we can get'. But if that does not work with a11y then maybe we
> need to land those patches later so that we can land them fully localized?
> We can always do small incremental updates after our v1 with a11y
> improvements.
>

> Also, I expect that we'll be adding/updating a11y labels as
> we continue to refine our UI tests since KIF and a11y strings are
> tightly coupled.
>

> Emily ran into an issue where labels are sometimes unpredictable. Like
> when they are dynamic. I wonder if we should start using accessibility
> identifiers more consistently instead. AFAIK those are not end-user facing
> and can be used to pinpoint specific elements without relying on strings or
> localized strings. What do you think?
>

> S.
>
>

Jeffrey Beatty

unread,

Jul 9, 2015, 8:14:21 PM7/9/15

to Stefan Arentz, Martin Jernberg, dev-l10n, bnicholson, Dwayne Bailey, mobile-firefox-dev

The last export from this week has not yet landed in Pootle. I'm hoping
Dwayne will speak to this when he's able.

Jeff