Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED FIXED in Firefox 15

Status

()

Firefox
Developer Tools: Console
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Gavin, Assigned: jwalker)

Tracking

Trunk
Firefox 15
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed-in-fx-team])

Attachments

(1 attachment)

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.
Blocks: 745773
No longer blocks: 720641
Status: NEW → ASSIGNED
Depends on: 720641
Target Milestone: --- → Firefox 15
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.
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
(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?
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.
(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?
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
Created attachment 623142 [details] [diff] [review]
Upload 1

a.k.a https://github.com/campd/gcli/pull/36
Attachment #623142 - Flags: review?(francesco.lodolo)
Attachment #623142 - Flags: review?(dcamp)
Attachment #623142 - Flags: review?(francesco.lodolo) → review+
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
Attachment #623142 - Flags: review?(dcamp) → review+
Try before land:
https://tbpl.mozilla.org/?tree=Try&rev=eba127ab7962

Fx-Team:
https://tbpl.mozilla.org/?tree=Fx-Team&rev=0f08ab4dfcac
Whiteboard: [fixed-in-fx-team]

Updated

5 years ago
No longer depends on: 720641

Updated

5 years ago
Depends on: 720641
https://tbpl.mozilla.org/?rev=9cb840a34394
https://hg.mozilla.org/mozilla-central/rev/9cb840a34394
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.