750318 - localization note and string ID change required for helpSearchManual in gcli.properties

Status: RESOLVED FIXED

(DevTools :: Console, defect)

Description

[:Gavin Sharp [email: [e-mail]]]

See bug 720641 comment 102 - the patch in that bug updated the helpSearchManual in gcli.properties but didn't change the entity name. Additionally, there is some confusion about the HTML <strong> formatting being included in the string, which could be clarified using an L10N note.

Comment 1

[Joe Walker [:jwalker]]

Just thinking about this - I'd like some clarification on when we need to change the key and when not.

This patch changed 2 strings, both as simplifications/clarifications:

-    helpSearchManual: 'A search string to use in narrowing down the list of commands that are displayed to the user. Any part of the command name can match, regular expressions are not supported.',
+    helpSearchManual: '<strong>search string</strong> to use in narrowing down the displayed commands. Regular expressions not supported.',

i.e. I added <strong> around 'search string' and changed 'commands that are displayed to the user' to 'displayed commands'. I also removed 'Any part of the command name can match'.

Also:

-    prefSetSettingManual: 'The name of the setting to alter. Must be an exact match.',
+    prefSetSettingManual: 'The name of the setting to alter.',

i.e. I removed ' Must be an exact match.'

By changing the key, I force all localizations to 'start again' with that message. By leaving it, I allow localizers to concentrate on other untranslated messages, which *for developer tools* could be a good trade-off?


I've added a note clarifying use of <strong>.

Also, if we decide we do need to change the keys, I'm thinking that it's OK to use helpSearchManual2 and prefSetSettingManual2. There is a naming standard that I follow in generating these keys, so other ways to change the keys seem destructive.

Comment 2

[Francesco Lodolo [:flod]]

This is a starting point
https://developer.mozilla.org/en/Making_String_Changes

About prefSetSettingManual. Where/when did you change it? For me that string landed "as new" in changeset 86623a74f82a, no modifications before or after.

http://hg.mozilla.org/mozilla-central/rev/86623a74f82a#l83.94

Comment 3

[Joe Walker [:jwalker]]

(In reply to Francesco Lodolo [:flod] from comment #2)
> This is a starting point
> https://developer.mozilla.org/en/Making_String_Changes

So on a trivial level, I'm not 'changing a string such that its meaning has changed', so I think there is nothing to do here.

> About prefSetSettingManual. Where/when did you change it? For me that string
> landed "as new" in changeset 86623a74f82a, no modifications before or after.
> 
> http://hg.mozilla.org/mozilla-central/rev/86623a74f82a#l83.94

Ah - I guess I added it and then corrected it, and then merged the changes so you didn't get to see!

So I'm planning on closing this bug - is that OK?

Comment 4

[Francesco Lodolo [:flod]]

No, in this case you're changing the string (you said it yourself, you wanted to simplify it): you added markup (<strong>), you cut off a significant piece of string ("Any part of the command name can match"), that's totally different from fixing language style or typos.

Comment 5

[Joe Walker [:jwalker]]

(In reply to Francesco Lodolo [:flod] from comment #4)
> No, in this case you're changing the string (you said it yourself, you
> wanted to simplify it): you added markup (<strong>), you cut off a
> significant piece of string ("Any part of the command name can match"),
> that's totally different from fixing language style or typos.

So to the other question of key naming. 'helpSearchManual' - 'help' is the command name, 'search' is the parameter name and 'manual' is the thing that we're providing. Renaming the command every time we change the description of the command is silly, the parameter names are similarly fixed, and to change the thing we're providing would be a huge change - so there are no obvious fixes, hence my suggestion of adding a 2.
Do you have any better solutions?

Comment 6

[Francesco Lodolo [:flod]]

Adding a 2 is not perfect but AFAIK it the most easy way to fix this kind of problems (you'll find plenty of these *2 keys in Mozilla's locale folders).

Don't forget also all references in l10n comments to helpSearchManual

Comment 7

[Joe Walker [:jwalker]]

Attachment: Upload 1

a.k.a https://github.com/campd/gcli/pull/36

Comment 8

[Joe Walker [:jwalker]]

Relevant tries:
https://tbpl.mozilla.org/?tree=Try&rev=27b9b61a663e
https://tbpl.mozilla.org/?tree=Try&rev=77b47c8bbc35
https://tbpl.mozilla.org/?tree=Try&rev=1ce36097dc58

Comment 9

[Joe Walker [:jwalker]]

Try before land:
https://tbpl.mozilla.org/?tree=Try&rev=eba127ab7962

Fx-Team:
https://tbpl.mozilla.org/?tree=Fx-Team&rev=0f08ab4dfcac

Comment 10

[Joe Walker [:jwalker]]

https://tbpl.mozilla.org/?rev=9cb840a34394
https://hg.mozilla.org/mozilla-central/rev/9cb840a34394