Settings: Internet: I18N

Settings: Internet: I18N

This provides localized strings for the MD Settings Internet page.

This CL also correctly sorts html includes and CSS properties to conform to Settings style.

BUG=512214
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Committed: https://crrev.com/fd6e7c1f910194027ed76f93ddeaf178cda64b5d
Cr-Commit-Position: refs/heads/master@{#415500}

[stevenjb, 2016-08-24 18:58:12]

Description was changed from

==========
Settings: Internet: I18N

This provides localized strings for the MD Settings Internet page.

BUG=512214
==========

to

==========
Settings: Internet: I18N

This provides localized strings for the MD Settings Internet page.

BUG=512214
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

[stevenjb, 2016-08-24 19:02:04]

Description was changed from

==========
Settings: Internet: I18N

This provides localized strings for the MD Settings Internet page.

BUG=512214
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

to

==========
Settings: Internet: I18N

This provides localized strings for the MD Settings Internet page.

This CL also correctly sorts html includes and CSS properties to conform to
Settings style.

BUG=512214
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

[stevenjb, 2016-08-24 19:03:02]

stevenjb@chromium.org changed reviewers:
+ dschuyler@chromium.org

[dschuyler, 2016-08-24 22:08:44]

Thanks for doing this!

Much of my comments are about shortening 
tag or const names. I didn't mark every 
instance. Let me know if more examples or 
description would help. For the most part 
it's about keeping the tags short and being
literal where practical.

On the desc= tags: I've gone through the 
process of a translator not understanding a
desc= and seen the trail of person-to-person
hand off of the question "what does this mean".
It seems worthwhile to reduce that hassle 
for them were we can :)

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
File chrome/app/settings_strings.grdp (right):

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
chrome/app/settings_strings.grdp:864: <message
name="IDS_SETTINGS_INTERNET_NETWORK_SECTION_ACCESS_POINT" desc="Settings >
Internet > Network details: Access Point section label.">
For many of the name= entries: how about
shortening the IDS by removing word(s)?

Maybe:

IDS_SETTINGS_INTERNET_NETWORK_SECTION_ACCESS_POINT
to
IDS_SETTINGS_NETWORK_ACCESS_POINT

(I'm also cool with IDS_SETTINGS_INTERNET_*
without _NETWORK, if you'd like to change them 
to that. Having INTERNET, NETWORK, and SECTION 
seems unnecessary).

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
chrome/app/settings_strings.grdp:867: <message
name="IDS_SETTINGS_INTERNET_NETWORK_SECTION_ADVANCED" desc="Settings > Internet
> Network details: Advanced section label.">
I'm trying to decide if the path, such as
Settings > Internet >
is an innovation we should use everywhere 
or if it's unnecessary and should be removed.
I think the desc= read and convey meaning fine 
without the path saying where the text is used.
I also wonder if the path may be another thing
to maintain if something about the where the
text is used were to shift.

Can you help me understand better why the path
is needed? Or remove them so I'm not distracted
by them :)

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
chrome/app/settings_strings.grdp:952: Your SIM card will be permanently disabled
if you cannot enter
Will it be permanently disable if they don't
enter the key - or will is that only if 
they enter one more invalid key. I.e. what 
if they do nothing here? It sounds like they
must enter it right now or all is lost.

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
chrome/app/settings_strings.grdp:1028: connected
It's fine if this should be lower case, but I 
wondered if the 'c' should be 'C'. (I'm asking,
not saying :) ).

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
chrome/app/settings_strings.grdp:1033: <message
name="IDS_SETTINGS_ONC_IPV4_ADDRESS" desc="ONC Property label for
ipv4-IPAddress">
ONC_ is fine in the name=, but the desc= is for
a translator who may not be an expert with acronyms.
Googling ONC doesn't show Open Network Configuration
right off. So I think it's uncommon enough that it 
is worth spelling out for a translator.

Hmm, in many cases, it looks like the ONC aspect 
could be omitted from the desc=, i.e. does the 
translator going to translate "IP address" to 
something different if it's ONC?

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
chrome/app/settings_strings.grdp:1048: <message
name="IDS_SETTINGS_ONC_CELLULAR_ACTIVATION_STATE_ACTIVATED" desc="ONC Property
value when Cellular.ActivationState = Activated">
Can this be written a different way?
"Cellular.ActivationState = Activated"
It seems like it may be cryptic for a 
non-coder. I'm guessing the translator
will just want to know how to correctly
translate it.

https://codereview.chromium.org/2273093002/diff/20001/chrome/browser/resource...
File chrome/browser/resources/settings/internet_page/internet_detail_page.html
(right):

https://codereview.chromium.org/2273093002/diff/20001/chrome/browser/resource...
chrome/browser/resources/settings/internet_page/internet_detail_page.html:26:
:root {
Could this be :host instead of :root?

https://codereview.chromium.org/2273093002/diff/20001/chrome/browser/resource...
chrome/browser/resources/settings/internet_page/internet_detail_page.html:89:
$i18n{networkButtonForget}
Let's remove "networkButton" and go with
$i18n{forget}.

(Or $i18n{networkForget} if some prefix
is desired). 

Similarly for the other i18n tags.

https://codereview.chromium.org/2273093002/diff/20001/chrome/browser/resource...
chrome/browser/resources/settings/internet_page/internet_detail_page.html:117:
$i18n{networkShared}
networkShared is good here. 
(As a counter-example to trying to be
more literal to the text being replaced.
If the text is long, a summary like this
is good).

https://codereview.chromium.org/2273093002/diff/20001/chrome/browser/resource...
chrome/browser/resources/settings/internet_page/internet_detail_page.html:124:
$i18n{networkPreferLabel}
This is still short enough that
$i18n{preferThisNetwork} would be a 
good i18n tag name.

[stevenjb, 2016-08-25 20:44:23]

Thanks for the careful review. I understand your perspective and genuinely
appreciate the feedback.

In general:
* I prefer more descriptive names in code for searchability. In particular,
there is no direct tie between IDS_FOO_BAR and $i18n{fooBar} so unless fooBar is
searchable it can be a huge pain to track it down (I've been there).
 
* I try to provide some context in the IDS descriptions, but one has to assume a
certain amount of familiarity with the product and the specific feature,
otherwise even a good description isn't helpful. E.g. if a translator can't
figure out what ONC is in the context of Chrome, then I am not going to be able
to explain what an "Access Point Name" is in a reasonable amount of text.

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
File chrome/app/settings_strings.grdp (right):

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
chrome/app/settings_strings.grdp:864: <message
name="IDS_SETTINGS_INTERNET_NETWORK_SECTION_ACCESS_POINT" desc="Settings >
Internet > Network details: Access Point section label.">
On 2016/08/24 22:08:43, dschuyler wrote:
> For many of the name= entries: how about
> shortening the IDS by removing word(s)?
> 
> Maybe:
> 
> IDS_SETTINGS_INTERNET_NETWORK_SECTION_ACCESS_POINT
> to
> IDS_SETTINGS_NETWORK_ACCESS_POINT
> 
> (I'm also cool with IDS_SETTINGS_INTERNET_*
> without _NETWORK, if you'd like to change them 
> to that. Having INTERNET, NETWORK, and SECTION 
> seems unnecessary).

Is there any particular value to shortening the names? The 'SETTINGS_INTERNET'
part is for strings specific to the settings internet section. The rest is
intended to be descriptive to the context and use (at least it is to me).

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
chrome/app/settings_strings.grdp:867: <message
name="IDS_SETTINGS_INTERNET_NETWORK_SECTION_ADVANCED" desc="Settings > Internet
> Network details: Advanced section label.">
On 2016/08/24 22:08:43, dschuyler wrote:
> I'm trying to decide if the path, such as
> Settings > Internet >
> is an innovation we should use everywhere 
> or if it's unnecessary and should be removed.
> I think the desc= read and convey meaning fine 
> without the path saying where the text is used.
> I also wonder if the path may be another thing
> to maintain if something about the where the
> text is used were to shift.
> 
> Can you help me understand better why the path
> is needed? Or remove them so I'm not distracted
> by them :)

Context is pretty essential to good translations, and this allows a
knowledgeable translator to find the string in context. Specifying a file name,
etc, might have maintenance problems, but if we don't have an Internet > Network
details section then we probably won't need these strings :)

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
chrome/app/settings_strings.grdp:952: Your SIM card will be permanently disabled
if you cannot enter
On 2016/08/24 22:08:43, dschuyler wrote:
> Will it be permanently disable if they don't
> enter the key - or will is that only if 
> they enter one more invalid key. I.e. what 
> if they do nothing here? It sounds like they
> must enter it right now or all is lost.

All of this text has been through UX in the previous incarnation. The user can
close the dialog, but the SIM is in that state permanently, they will need to
enter the correct PUK (PIN Unblocking Key) before they can access it, and they
have a limited number of tries (also indicated).

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
chrome/app/settings_strings.grdp:1028: connected
On 2016/08/24 22:08:43, dschuyler wrote:
> It's fine if this should be lower case, but I 
> wondered if the 'c' should be 'C'. (I'm asking,
> not saying :) ).

I know it looks odd here, but yes this is from UX. It looks less odd in context.
Thanks for double checking.

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
chrome/app/settings_strings.grdp:1033: <message
name="IDS_SETTINGS_ONC_IPV4_ADDRESS" desc="ONC Property label for
ipv4-IPAddress">
On 2016/08/24 22:08:43, dschuyler wrote:
> ONC_ is fine in the name=, but the desc= is for
> a translator who may not be an expert with acronyms.
> Googling ONC doesn't show Open Network Configuration
> right off. So I think it's uncommon enough that it 
> is worth spelling out for a translator.
> 
> Hmm, in many cases, it looks like the ONC aspect 
> could be omitted from the desc=, i.e. does the 
> translator going to translate "IP address" to 
> something different if it's ONC?

Google "ONC Chrome". That doc should help a knowledgeable translator gain
context if necessary.

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
chrome/app/settings_strings.grdp:1048: <message
name="IDS_SETTINGS_ONC_CELLULAR_ACTIVATION_STATE_ACTIVATED" desc="ONC Property
value when Cellular.ActivationState = Activated">
On 2016/08/24 22:08:43, dschuyler wrote:
> Can this be written a different way?
> "Cellular.ActivationState = Activated"
> It seems like it may be cryptic for a 
> non-coder. I'm guessing the translator
> will just want to know how to correctly
> translate it.

The properties are described in the ONC spec. Copying all of that here seems
tedious and unnecessary :)

https://codereview.chromium.org/2273093002/diff/20001/chrome/browser/resource...
File chrome/browser/resources/settings/internet_page/internet_detail_page.html
(right):

https://codereview.chromium.org/2273093002/diff/20001/chrome/browser/resource...
chrome/browser/resources/settings/internet_page/internet_detail_page.html:26:
:root {
On 2016/08/24 22:08:43, dschuyler wrote:
> Could this be :host instead of :root?

Er, yes, thanks. Done.

https://codereview.chromium.org/2273093002/diff/20001/chrome/browser/resource...
chrome/browser/resources/settings/internet_page/internet_detail_page.html:89:
$i18n{networkButtonForget}
On 2016/08/24 22:08:43, dschuyler wrote:
> Let's remove "networkButton" and go with
> $i18n{forget}.
> 
> (Or $i18n{networkForget} if some prefix
> is desired). 
> 
> Similarly for the other i18n tags.

Keep in mind these tags are global. Is there any particular value to shortening
them?

https://codereview.chromium.org/2273093002/diff/20001/chrome/browser/resource...
chrome/browser/resources/settings/internet_page/internet_detail_page.html:117:
$i18n{networkShared}
On 2016/08/24 22:08:43, dschuyler wrote:
> networkShared is good here. 
> (As a counter-example to trying to be
> more literal to the text being replaced.
> If the text is long, a summary like this
> is good).

Acknowledged.

https://codereview.chromium.org/2273093002/diff/20001/chrome/browser/resource...
chrome/browser/resources/settings/internet_page/internet_detail_page.html:124:
$i18n{networkPreferLabel}
On 2016/08/24 22:08:43, dschuyler wrote:
> This is still short enough that
> $i18n{preferThisNetwork} would be a 
> good i18n tag name.

Since tags are global I find them easier to find when debugging when they use
subjectAdjective ordering instead of English word ordering, e.g. canaryYellow vs
yellowCanary.

[Dan Beam, 2016-08-25 21:56:30]

On 2016/08/25 20:44:23, stevenjb wrote:
> In particular,
> there is no direct tie between IDS_FOO_BAR and $i18n{fooBar} so unless fooBar
is
> searchable it can be a huge pain to track it down (I've been there).

yes, I don't see a huge benefit to this mapping and it's quite common.  I think
just using IDS_ directly in the future might be in the cards :).

[stevenjb, 2016-08-25 21:58:47]

On 2016/08/25 21:56:30, Dan Beam wrote:
> On 2016/08/25 20:44:23, stevenjb wrote:
> > In particular,
> > there is no direct tie between IDS_FOO_BAR and $i18n{fooBar} so unless
fooBar
> is
> > searchable it can be a huge pain to track it down (I've been there).
> 
> yes, I don't see a huge benefit to this mapping and it's quite common.  I
think
> just using IDS_ directly in the future might be in the cards :).

I would be hugely in favor of that. In the early stages of Settings I had
notions of eliminating the need for something like
md_settings_localized_strings_provider.cc, but as you are both well aware,
localization is... complicated :)

[dschuyler, 2016-08-26 01:32:51]

LGTM

I've put in some responses to the questions asked.
I'm not intending to argue the points, just trying
to explain where the suggestions came from.

Overall, there are a few perfectly fine ways to 
do this stuff. Maybe we should do it differently
than we have been.

I'd be up for chatting about it further, but I don't 
want to hold up this CL.

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
File chrome/app/settings_strings.grdp (right):

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
chrome/app/settings_strings.grdp:864: <message
name="IDS_SETTINGS_INTERNET_NETWORK_SECTION_ACCESS_POINT" desc="Settings >
Internet > Network details: Access Point section label.">
On 2016/08/25 20:44:22, stevenjb wrote:
> On 2016/08/24 22:08:43, dschuyler wrote:
> > For many of the name= entries: how about
> > shortening the IDS by removing word(s)?
> > 
> > Maybe:
> > 
> > IDS_SETTINGS_INTERNET_NETWORK_SECTION_ACCESS_POINT
> > to
> > IDS_SETTINGS_NETWORK_ACCESS_POINT
> > 
> > (I'm also cool with IDS_SETTINGS_INTERNET_*
> > without _NETWORK, if you'd like to change them 
> > to that. Having INTERNET, NETWORK, and SECTION 
> > seems unnecessary).
> 
> Is there any particular value to shortening the names? The 'SETTINGS_INTERNET'
> part is for strings specific to the settings internet section. The rest is
> intended to be descriptive to the context and use (at least it is to me).

In the near term keeping the names shorter is easier on human
programmers (but this is a matter of opinion). In the long term
there is an intent to generate the i18n tags from IDS names, and
long i18n tags mean larger code code to load and larger translation
tables/maps.

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
chrome/app/settings_strings.grdp:867: <message
name="IDS_SETTINGS_INTERNET_NETWORK_SECTION_ADVANCED" desc="Settings > Internet
> Network details: Advanced section label.">
On 2016/08/25 20:44:22, stevenjb wrote:
> On 2016/08/24 22:08:43, dschuyler wrote:
> > I'm trying to decide if the path, such as
> > Settings > Internet >
> > is an innovation we should use everywhere 
> > or if it's unnecessary and should be removed.
> > I think the desc= read and convey meaning fine 
> > without the path saying where the text is used.
> > I also wonder if the path may be another thing
> > to maintain if something about the where the
> > text is used were to shift.
> > 
> > Can you help me understand better why the path
> > is needed? Or remove them so I'm not distracted
> > by them :)
> 
> Context is pretty essential to good translations, and this allows a
> knowledgeable translator to find the string in context. Specifying a file
name,
> etc, might have maintenance problems, but if we don't have an Internet >
Network
> details section then we probably won't need these strings :)

My rough understanding was an intent to reduce the need for extra
strings being defined. i.e. if two tags are referring to the same
text in two different sections, there's no need to define two tags
to the same translations in the translation table/map.

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
chrome/app/settings_strings.grdp:1033: <message
name="IDS_SETTINGS_ONC_IPV4_ADDRESS" desc="ONC Property label for
ipv4-IPAddress">
On 2016/08/25 20:44:22, stevenjb wrote:
> On 2016/08/24 22:08:43, dschuyler wrote:
> > ONC_ is fine in the name=, but the desc= is for
> > a translator who may not be an expert with acronyms.
> > Googling ONC doesn't show Open Network Configuration
> > right off. So I think it's uncommon enough that it 
> > is worth spelling out for a translator.
> > 
> > Hmm, in many cases, it looks like the ONC aspect 
> > could be omitted from the desc=, i.e. does the 
> > translator going to translate "IP address" to 
> > something different if it's ONC?
> 
> Google "ONC Chrome". That doc should help a knowledgeable translator gain
> context if necessary.
> 

I think removing the ONC reference may still be productive, with the thinking
that 'IP address' under ONC is the same as 'IP address' not under ONC?

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
chrome/app/settings_strings.grdp:1048: <message
name="IDS_SETTINGS_ONC_CELLULAR_ACTIVATION_STATE_ACTIVATED" desc="ONC Property
value when Cellular.ActivationState = Activated">
On 2016/08/25 20:44:22, stevenjb wrote:
> On 2016/08/24 22:08:43, dschuyler wrote:
> > Can this be written a different way?
> > "Cellular.ActivationState = Activated"
> > It seems like it may be cryptic for a 
> > non-coder. I'm guessing the translator
> > will just want to know how to correctly
> > translate it.
> 
> The properties are described in the ONC spec. Copying all of that here seems
> tedious and unnecessary :)

I wouldn't expect that a translator had read the ONC spec.
Maybe:
"Property value showing the cellular network state is activated."
I'm trying to suggest that the desc= be more English and have a
less technical style.

https://codereview.chromium.org/2273093002/diff/20001/chrome/browser/resource...
File chrome/browser/resources/settings/internet_page/internet_detail_page.html
(right):

https://codereview.chromium.org/2273093002/diff/20001/chrome/browser/resource...
chrome/browser/resources/settings/internet_page/internet_detail_page.html:89:
$i18n{networkButtonForget}
On 2016/08/25 20:44:23, stevenjb wrote:
> On 2016/08/24 22:08:43, dschuyler wrote:
> > Let's remove "networkButton" and go with
> > $i18n{forget}.
> > 
> > (Or $i18n{networkForget} if some prefix
> > is desired). 
> > 
> > Similarly for the other i18n tags.
> 
> Keep in mind these tags are global. Is there any particular value to
shortening
> them?

The valuable aspects are 
+ reducing bytes in the HTML (parsing and IO) 
+ reducing time/space spent in the translation (i18n).
+ readability of the code
+ a tendency to reduce duplication in the translations
+ I believe there is already dupe (or name collision) detection

https://codereview.chromium.org/2273093002/diff/20001/chrome/browser/resource...
chrome/browser/resources/settings/internet_page/internet_detail_page.html:124:
$i18n{networkPreferLabel}
On 2016/08/25 20:44:23, stevenjb wrote:
> On 2016/08/24 22:08:43, dschuyler wrote:
> > This is still short enough that
> > $i18n{preferThisNetwork} would be a 
> > good i18n tag name.
> 
> Since tags are global I find them easier to find when debugging when they use
> subjectAdjective ordering instead of English word ordering, e.g. canaryYellow
vs
> yellowCanary.

That's a reasonable choice. I'm cool switching to that. I'm going
by call made early on in the process (over a year ago) to go the
other way. While I'm cool with choice A or choice B, I'd rather
not have a mix of A and B.

[stevenjb, 2016-08-26 16:48:28]

Patchset #5 (id:80001) has been deleted

[stevenjb, 2016-08-26 16:48:51]

PTAL (non-trivial changes)

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
File chrome/app/settings_strings.grdp (right):

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
chrome/app/settings_strings.grdp:864: <message
name="IDS_SETTINGS_INTERNET_NETWORK_SECTION_ACCESS_POINT" desc="Settings >
Internet > Network details: Access Point section label.">
On 2016/08/26 01:32:51, dschuyler wrote:
> On 2016/08/25 20:44:22, stevenjb wrote:
> > On 2016/08/24 22:08:43, dschuyler wrote:
> > > For many of the name= entries: how about
> > > shortening the IDS by removing word(s)?
> > > 
> > > Maybe:
> > > 
> > > IDS_SETTINGS_INTERNET_NETWORK_SECTION_ACCESS_POINT
> > > to
> > > IDS_SETTINGS_NETWORK_ACCESS_POINT
> > > 
> > > (I'm also cool with IDS_SETTINGS_INTERNET_*
> > > without _NETWORK, if you'd like to change them 
> > > to that. Having INTERNET, NETWORK, and SECTION 
> > > seems unnecessary).
> > 
> > Is there any particular value to shortening the names? The
'SETTINGS_INTERNET'
> > part is for strings specific to the settings internet section. The rest is
> > intended to be descriptive to the context and use (at least it is to me).
> 
> In the near term keeping the names shorter is easier on human
> programmers (but this is a matter of opinion). In the long term
> there is an intent to generate the i18n tags from IDS names, and
> long i18n tags mean larger code code to load and larger translation
> tables/maps.

I'm not sure if I agree with the "easier on human programmers" statement. I
would definitely argue that it is subjective. I prefer greater specificity.

WRT long term, I would argue that the IDS tags are on average much to long to
convert straight to JS tags and we will need to do some sort of namespacing or
renaming across the board. (I would also suggest that is in all likelihood far
in the future).

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
chrome/app/settings_strings.grdp:867: <message
name="IDS_SETTINGS_INTERNET_NETWORK_SECTION_ADVANCED" desc="Settings > Internet
> Network details: Advanced section label.">
On 2016/08/26 01:32:51, dschuyler wrote:
> On 2016/08/25 20:44:22, stevenjb wrote:
> > On 2016/08/24 22:08:43, dschuyler wrote:
> > > I'm trying to decide if the path, such as
> > > Settings > Internet >
> > > is an innovation we should use everywhere 
> > > or if it's unnecessary and should be removed.
> > > I think the desc= read and convey meaning fine 
> > > without the path saying where the text is used.
> > > I also wonder if the path may be another thing
> > > to maintain if something about the where the
> > > text is used were to shift.
> > > 
> > > Can you help me understand better why the path
> > > is needed? Or remove them so I'm not distracted
> > > by them :)
> > 
> > Context is pretty essential to good translations, and this allows a
> > knowledgeable translator to find the string in context. Specifying a file
> name,
> > etc, might have maintenance problems, but if we don't have an Internet >
> Network
> > details section then we probably won't need these strings :)
> 
> My rough understanding was an intent to reduce the need for extra
> strings being defined. i.e. if two tags are referring to the same
> text in two different sections, there's no need to define two tags
> to the same translations in the translation table/map.

Context is a huge part of translation. We should never use, for example, the
same string for a title and for a button label, they often need to be translated
differently.

That said, some of this is not settings-specific per-se. I have moved the
<cr-network-list> and onc property strings to separate, documented sections,
which should help alleviate some of the concerns listed (and shorten those names
for you :) ).

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
chrome/app/settings_strings.grdp:1033: <message
name="IDS_SETTINGS_ONC_IPV4_ADDRESS" desc="ONC Property label for
ipv4-IPAddress">
On 2016/08/26 01:32:51, dschuyler wrote:
> On 2016/08/25 20:44:22, stevenjb wrote:
> > On 2016/08/24 22:08:43, dschuyler wrote:
> > > ONC_ is fine in the name=, but the desc= is for
> > > a translator who may not be an expert with acronyms.
> > > Googling ONC doesn't show Open Network Configuration
> > > right off. So I think it's uncommon enough that it 
> > > is worth spelling out for a translator.
> > > 
> > > Hmm, in many cases, it looks like the ONC aspect 
> > > could be omitted from the desc=, i.e. does the 
> > > translator going to translate "IP address" to 
> > > something different if it's ONC?
> > 
> > Google "ONC Chrome". That doc should help a knowledgeable translator gain
> > context if necessary.
> > 
> 
> I think removing the ONC reference may still be productive, with the thinking
> that 'IP address' under ONC is the same as 'IP address' not under ONC?

Most people know what an IP Address is, but 'Gateway' is likely translated very
differently depending on its context :)

https://codereview.chromium.org/2273093002/diff/20001/chrome/app/settings_str...
chrome/app/settings_strings.grdp:1048: <message
name="IDS_SETTINGS_ONC_CELLULAR_ACTIVATION_STATE_ACTIVATED" desc="ONC Property
value when Cellular.ActivationState = Activated">
On 2016/08/26 01:32:51, dschuyler wrote:
> On 2016/08/25 20:44:22, stevenjb wrote:
> > On 2016/08/24 22:08:43, dschuyler wrote:
> > > Can this be written a different way?
> > > "Cellular.ActivationState = Activated"
> > > It seems like it may be cryptic for a 
> > > non-coder. I'm guessing the translator
> > > will just want to know how to correctly
> > > translate it.
> > 
> > The properties are described in the ONC spec. Copying all of that here seems
> > tedious and unnecessary :)
> 
> I wouldn't expect that a translator had read the ONC spec.
> Maybe:
> "Property value showing the cellular network state is activated."
> I'm trying to suggest that the desc= be more English and have a
> less technical style.

See above. It is actually crucial that the translator have some technical
knowledge. I don't know how good we are at that, but I would suggest that a
little information will sometimes be harmful, and copy/pasting the ONC spec here
is impractical. (For example, 'cellular network state' actually refers to
connected / connecting / not connected; activation state is separate, so this
would need to be 'The carrier account activation state for a cellular network'.
Now multiply that by 50).

https://codereview.chromium.org/2273093002/diff/20001/chrome/browser/resource...
File chrome/browser/resources/settings/internet_page/internet_detail_page.html
(right):

https://codereview.chromium.org/2273093002/diff/20001/chrome/browser/resource...
chrome/browser/resources/settings/internet_page/internet_detail_page.html:89:
$i18n{networkButtonForget}
On 2016/08/26 01:32:51, dschuyler wrote:
> On 2016/08/25 20:44:23, stevenjb wrote:
> > On 2016/08/24 22:08:43, dschuyler wrote:
> > > Let's remove "networkButton" and go with
> > > $i18n{forget}.
> > > 
> > > (Or $i18n{networkForget} if some prefix
> > > is desired). 
> > > 
> > > Similarly for the other i18n tags.
> > 
> > Keep in mind these tags are global. Is there any particular value to
> shortening
> > them?
> 
> The valuable aspects are 
> + reducing bytes in the HTML (parsing and IO) 
Valid, but I personally don't think that trumps searchability.

> + reducing time/space spent in the translation (i18n).
This I don't follow.

> + readability of the code
Again, subjective. I prefer extra context.

> + a tendency to reduce duplication in the translations
See earlier comment.

> + I believe there is already dupe (or name collision) detection
Sure, but who gets to use, e.g. 'configure'? (Which, BTW, will translate
differently depending on the context, i.e. 'configure [network]' is different
from 'configure [bluetooth device]' depending on the gender of 'network' and
'bluetooth device').

https://codereview.chromium.org/2273093002/diff/20001/chrome/browser/resource...
chrome/browser/resources/settings/internet_page/internet_detail_page.html:124:
$i18n{networkPreferLabel}
On 2016/08/26 01:32:51, dschuyler wrote:
> On 2016/08/25 20:44:23, stevenjb wrote:
> > On 2016/08/24 22:08:43, dschuyler wrote:
> > > This is still short enough that
> > > $i18n{preferThisNetwork} would be a 
> > > good i18n tag name.
> > 
> > Since tags are global I find them easier to find when debugging when they
use
> > subjectAdjective ordering instead of English word ordering, e.g.
canaryYellow
> vs
> > yellowCanary.
> 
> That's a reasonable choice. I'm cool switching to that. I'm going
> by call made early on in the process (over a year ago) to go the
> other way. While I'm cool with choice A or choice B, I'd rather
> not have a mix of A and B.

Ah, I was unaware that had been previously discussed. I don't suppose we
documented the decision? I expect this is one where the decision would be
"developer choice" :)

[stevenjb, 2016-08-26 16:50:05]

P.S. Apologies if any of my responses sound argumentative, that wasn't my
intent. I think this is a useful discussion and value exchanging perspectives.

[dschuyler, 2016-08-26 18:32:17]

https://codereview.chromium.org/2273093002/diff/100001/chrome/browser/ui/webu...
File chrome/browser/ui/webui/settings/md_settings_localized_strings_provider.cc
(right):

https://codereview.chromium.org/2273093002/diff/100001/chrome/browser/ui/webu...
chrome/browser/ui/webui/settings/md_settings_localized_strings_provider.cc:1448:
// with translatable enumerated values have the value appended after '_'.
I'm still hoping to get to the point were the i18n
tag names are auto-generated from the IDS names.
Will this will make that transition harder?

[stevenjb, 2016-08-26 19:30:26]

https://codereview.chromium.org/2273093002/diff/100001/chrome/browser/ui/webu...
File chrome/browser/ui/webui/settings/md_settings_localized_strings_provider.cc
(right):

https://codereview.chromium.org/2273093002/diff/100001/chrome/browser/ui/webu...
chrome/browser/ui/webui/settings/md_settings_localized_strings_provider.cc:1448:
// with translatable enumerated values have the value appended after '_'.
On 2016/08/26 18:32:17, dschuyler wrote:
> I'm still hoping to get to the point were the i18n
> tag names are auto-generated from the IDS names.
> Will this will make that transition harder?

Possibly. We will have to figure something out if/when we do that, either a
translation table maintained separately (ugh) or a different conversion scheme.
As long as these are macros we are very limited in what characters we can use.

[stevenjb, 2016-08-26 20:25:18]

https://codereview.chromium.org/2273093002/diff/100001/chrome/browser/ui/webu...
File chrome/browser/ui/webui/settings/md_settings_localized_strings_provider.cc
(right):

https://codereview.chromium.org/2273093002/diff/100001/chrome/browser/ui/webu...
chrome/browser/ui/webui/settings/md_settings_localized_strings_provider.cc:1448:
// with translatable enumerated values have the value appended after '_'.
On 2016/08/26 19:30:26, stevenjb wrote:
> On 2016/08/26 18:32:17, dschuyler wrote:
> > I'm still hoping to get to the point were the i18n
> > tag names are auto-generated from the IDS names.
> > Will this will make that transition harder?
> 
> Possibly. We will have to figure something out if/when we do that, either a
> translation table maintained separately (ugh) or a different conversion
scheme.
> As long as these are macros we are very limited in what characters we can use.
> 

Actually this shouldn't be a problem. These are already auto generated using _
instead of ., we can just apply whatever convention we use when we convert these
in the corresponding JS.

[stevenjb, 2016-08-29 21:43:11]

Rebased and fixed clang. PTAL when you have a chance, thanks!

[dschuyler, 2016-08-30 01:16:36]

I glanced over it again and tried to check
the newest changes. This is a bit of a RS LGTM
though.

My question below is because I'm assuming a
closure case is like a C style cast. I wasn't 
sure from this doc:
https://developers.google.com/closure/compiler/docs/js-for-compiler#typecasting

https://codereview.chromium.org/2273093002/diff/120001/chrome/browser/resourc...
File chrome/browser/resources/settings/internet_page/network_property_list.js
(right):

https://codereview.chromium.org/2273093002/diff/120001/chrome/browser/resourc...
chrome/browser/resources/settings/internet_page/network_property_list.js:173:
let valueStr = /** @type {string} */ (value);
Optional/just a question:
Is there a way this may not be a string
at this point? Is it worth asserting or
doing an early-out above this assignment?

[dschuyler, 2016-08-30 01:17:44]

On 2016/08/30 01:16:36, dschuyler wrote:
> I glanced over it again and tried to check
> the newest changes. This is a bit of a RS LGTM
> though.
> 
> My question below is because I'm assuming a
> closure case is like a C style cast. I wasn't 
> sure from this doc:
>
https://developers.google.com/closure/compiler/docs/js-for-compiler#typecasting
> 
>
https://codereview.chromium.org/2273093002/diff/120001/chrome/browser/resourc...
> File chrome/browser/resources/settings/internet_page/network_property_list.js
> (right):
> 
>
https://codereview.chromium.org/2273093002/diff/120001/chrome/browser/resourc...
> chrome/browser/resources/settings/internet_page/network_property_list.js:173:
> let valueStr = /** @type {string} */ (value);
> Optional/just a question:
> Is there a way this may not be a string
> at this point? Is it worth asserting or
> doing an early-out above this assignment?

s/case/cast/

[stevenjb, 2016-08-30 15:27:56]

https://codereview.chromium.org/2273093002/diff/120001/chrome/browser/resourc...
File chrome/browser/resources/settings/internet_page/network_property_list.js
(right):

https://codereview.chromium.org/2273093002/diff/120001/chrome/browser/resourc...
chrome/browser/resources/settings/internet_page/network_property_list.js:173:
let valueStr = /** @type {string} */ (value);
On 2016/08/30 01:16:36, dschuyler wrote:
> Optional/just a question:
> Is there a way this may not be a string
> at this point? Is it worth asserting or
> doing an early-out above this assignment?

It has to be a string at this point. propertyDict can't contain null, but the
compiler doesn't know that. The typecast is just to appease Closure. I can add
an assert to document that.

[stevenjb, 2016-08-30 15:31:43]

The CQ bit was checked by stevenjb@chromium.org

[stevenjb, 2016-08-30 15:31:44]

The patchset sent to the CQ was uploaded after l-g-t-m from
dschuyler@chromium.org
Link to the patchset: https://codereview.chromium.org/2273093002/#ps140001
(title: "Add assert")

[commit-bot: I haz the power, 2016-08-30 15:32:04]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-30 15:34:08]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-30 15:34:10]

Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[stevenjb, 2016-08-30 17:43:10]

The CQ bit was checked by stevenjb@chromium.org

[stevenjb, 2016-08-30 17:43:11]

The patchset sent to the CQ was uploaded after l-g-t-m from
dschuyler@chromium.org
Link to the patchset: https://codereview.chromium.org/2273093002/#ps160001
(title: "Rebase")

[commit-bot: I haz the power, 2016-08-30 17:44:04]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-30 20:34:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-30 20:34:36]

Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[stevenjb, 2016-08-30 22:31:16]

The CQ bit was checked by stevenjb@chromium.org

[commit-bot: I haz the power, 2016-08-30 22:31:55]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-30 23:57:21]

Description was changed from

==========
Settings: Internet: I18N

This provides localized strings for the MD Settings Internet page.

This CL also correctly sorts html includes and CSS properties to conform to
Settings style.

BUG=512214
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

to

==========
Settings: Internet: I18N

This provides localized strings for the MD Settings Internet page.

This CL also correctly sorts html includes and CSS properties to conform to
Settings style.

BUG=512214
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

[commit-bot: I haz the power, 2016-08-30 23:57:22]

Committed patchset #8 (id:160001)

[commit-bot: I haz the power, 2016-08-30 23:59:58]

Description was changed from

==========
Settings: Internet: I18N

This provides localized strings for the MD Settings Internet page.

This CL also correctly sorts html includes and CSS properties to conform to
Settings style.

BUG=512214
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation
==========

to

==========
Settings: Internet: I18N

This provides localized strings for the MD Settings Internet page.

This CL also correctly sorts html includes and CSS properties to conform to
Settings style.

BUG=512214
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Committed: https://crrev.com/fd6e7c1f910194027ed76f93ddeaf178cda64b5d
Cr-Commit-Position: refs/heads/master@{#415500}
==========

[commit-bot: I haz the power, 2016-08-30 23:59:59]

Patchset 8 (id:??) landed as
https://crrev.com/fd6e7c1f910194027ed76f93ddeaf178cda64b5d
Cr-Commit-Position: refs/heads/master@{#415500}