Last Comment Bug 717056 - More Android Sync setup strings
: More Android Sync setup strings
Status: RESOLVED FIXED
[inbound]
:
Product: Android Background Services
Classification: Client Software
Component: Android Sync (show other bugs)
: unspecified
: ARM Android
: -- normal
: mozilla12
Assigned To: Richard Newman [:rnewman]
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-10 14:56 PST by Chenxia Liu [:liuche]
Modified: 2013-04-04 13:48 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
fixed


Attachments
Proposed patch. v1 (4.73 KB, patch)
2012-01-10 19:06 PST, Richard Newman [:rnewman]
blassey.bugs: review+
Details | Diff | Splinter Review

Description Chenxia Liu [:liuche] 2012-01-10 14:56:39 PST
Used in screens when Android Sync fails due to lack of internet on device.

Changes on github:
https://github.com/mozilla-services/android-sync/commit/99214c4cc40d1cc1d6592afbc460017a6e12dd20#strings.xml.in

strings.xml.in and sync_strings.dtd.in
Comment 1 Chenxia Liu [:liuche] 2012-01-10 17:45:47 PST
Additional string changes, related to link handling.

https://github.com/mozilla-services/android-sync/commit/c02a50a3aa046b594fb23f1a2bcc31b19622039b#sync_strings.dtd.in
Comment 2 Richard Newman [:rnewman] 2012-01-10 19:05:58 PST
This change:

* Removes the embedded HTML from sync.link.* strings (Chenxia found an alternative approach);
* Adds sync.subtitle.nointernet.label and sync.button.ok.label.

As with Bug 716760, we're slipping these in ahead of time to get them into Aurora before a string freeze.
Comment 3 Richard Newman [:rnewman] 2012-01-10 19:06:25 PST
Created attachment 587573 [details] [diff] [review]
Proposed patch. v1
Comment 4 Richard Newman [:rnewman] 2012-01-10 22:57:50 PST
Thanks Brad!

Inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/5461d5635ca9
Comment 5 Ed Morley [:emorley] 2012-01-11 18:07:14 PST
https://hg.mozilla.org/mozilla-central/rev/5461d5635ca9
Comment 6 Francesco Lodolo [:flod] 2012-01-12 23:36:49 PST
Bad idea, I think you should have changed name entities here

-<!ENTITY sync.link.show.label '<a href="https://support.mozilla.com/kb/add-a-device-to-firefox-sync">Show me how</a>'>
-<!ENTITY sync.link.nodevice.label '<a href="#">I don\&apos;t have the device with me…</a>'>
+<!ENTITY sync.link.show.label 'Show me how.'>
+<!ENTITY sync.link.nodevice.label 'I don\&apos;t have the device with me…'>
Comment 7 Richard Newman [:rnewman] 2012-01-13 00:05:22 PST
(In reply to flod (Francesco Lodolo) from comment #6)
> Bad idea, I think you should have changed name entities here

Is that the case even for a preffed-off feature that has barely landed in Nightlies? (Genuine question, I was under the impression that nobody would have attempted to localize these strings yet.)
Comment 8 Francesco Lodolo [:flod] 2012-01-13 00:11:58 PST
I see 5 locales with wrong translations, and that's just because the other 6 already fixed these strings. 

http://mxr.mozilla.org/l10n-central/search?string=sync.link.show.label&find=%2Fmobile&findi=&filter=^[^\0]*%24&hitlimit=&tree=l10n-central

The alternative to change the entity name now is to keep those 6 locales under control or warn their owner if they don't catch the change.
Comment 9 Robert Kaiser 2012-01-13 06:21:45 PST
(In reply to Richard Newman [:rnewman] from comment #7)
> Is that the case even for a preffed-off feature that has barely landed in
> Nightlies? (Genuine question, I was under the impression that nobody would
> have attempted to localize these strings yet.)

As soon as something has landed, some people are going to start localizing it - and they don't see what's preffed off or on as the strings are there in the locales/ directory and showing up as "missing" strings in our L10n tools.
The best rule to follow is: Once strings have landed and you change them in a way that need localizers to look at them again when they already have localized the former ones, then you need to change the string IDs as well.
Comment 10 Richard Newman [:rnewman] 2012-01-13 09:24:56 PST
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #9)

> As soon as something has landed, some people are going to start localizing
> it - and they don't see what's preffed off or on as the strings are there in
> the locales/ directory and showing up as "missing" strings in our L10n tools.

I see. I got the impression from Axel recently that there was little point landing strings before the feature was available, because it would be difficult or impossible to localize; I suppose that meant "localize well"!

Thanks for clarifying.
Comment 11 Axel Hecht [pto-Aug-30][:Pike] 2012-01-13 10:42:25 PST
Right, that meant "localize well". That's all I care about so I don't mention it explicitly. Black magick.

To recap, don't spend time on prelanding strings but land the functional code. As even if you preland, you have to pretend that they're all correctly localized and be all paranoid, and that's really a lot of work for a string that's not used yet.
Comment 12 Brad Lassey [:blassey] (use needinfo?) 2012-01-27 23:46:27 PST
Richard, please request aurora approval
Comment 13 Richard Newman [:rnewman] 2012-01-27 23:55:04 PST
(In reply to Brad Lassey [:blassey] from comment #12)
> Richard, please request aurora approval

No need; already arrived in the 0.3 merge this week. Aurora and m-c are identical for Sync right now.

Note You need to log in before you can comment on or make changes to this bug.