799463 - GCLI jsb command should have nice html-free updates to jsbBraceStyleDesc and jsbBraceStyleManual strings

Status: RESOLVED FIXED

(DevTools Graveyard :: Graphic Commandline and Toolbar, defect)

Description

[Joe Walker [:jwalker]]

We'll need to change the string names, obviously.

Comment 1

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Attachment: Updated strings

Comment 2

[Axel Hecht [:Pike]]

Comment on attachment 669579 [details] [diff] [review]
Updated strings

Review of attachment 669579 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/locales/en-US/chrome/browser/devtools/gclicommands.properties
@@ +853,4 @@
>  # 'jsb <braceStyle>' parameter. This string is designed to be shown
>  # in a menu alongside the command name, which is why it should be as short as
>  # possible.
> +jsbBraceStyleDesc2=Select the coding style of braces

There's probably a more descriptive change to the key, I suggest to think about them as variable names. How about jsbSelectBraceStyleDesc?

@@ +859,3 @@
>  # 'jsb <braceStyle>' parameter, displayed when the user asks for help
>  # on what it does.
> +jsbBraceStyleManual2=Select the coding style of braces: collapse - put braces on the same line as control statements, expand - put braces on own line (Allman / ANSI style), end-expand - put end braces on own line or expand-strict - put brace on own line even if it will break your code.

I'd recommend to get a copy writer for this like Matej.

My non-native speaker suggestion would be to use ';' to separate the cases consistently (no or for the last one).

Comment 3

[Joe Walker [:jwalker]]

(In reply to Axel Hecht [:Pike] from comment #2)
> Comment on attachment 669579 [details] [diff] [review]
> Updated strings
> 
> Review of attachment 669579 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: browser/locales/en-US/chrome/browser/devtools/gclicommands.properties
> @@ +853,4 @@
> >  # 'jsb <braceStyle>' parameter. This string is designed to be shown
> >  # in a menu alongside the command name, which is why it should be as short as
> >  # possible.
> > +jsbBraceStyleDesc2=Select the coding style of braces
> 
> There's probably a more descriptive change to the key, I suggest to think
> about them as variable names. How about jsbSelectBraceStyleDesc?

This idea here is that this is the 'desc'ription of the 'braceStyle' parameter to the 'jsb' command. All GCLI parameter strings follow this basic pattern (<command><parameter><use>), and we add numbers to the end to avoid breaking the pattern needlessly.

Comment 4

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Attachment: Updated strings v2

(In reply to Axel Hecht [:Pike] from comment #2)
> Comment on attachment 669579 [details] [diff] [review]
> Updated strings
> 
> Review of attachment 669579 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: browser/locales/en-US/chrome/browser/devtools/gclicommands.properties
> @@ +853,4 @@
> >  # 'jsb <braceStyle>' parameter. This string is designed to be shown
> >  # in a menu alongside the command name, which is why it should be as short as
> >  # possible.
> > +jsbBraceStyleDesc2=Select the coding style of braces
> 
> There's probably a more descriptive change to the key, I suggest to think
> about them as variable names. How about jsbSelectBraceStyleDesc?
> 

This idea here is that this is the 'desc'ription of the 'braceStyle' parameter to the 'jsb' command. All GCLI parameter strings follow this basic pattern (<command><parameter><use>), and we add numbers to the end to avoid breaking the pattern needlessly.

> @@ +859,3 @@
> >  # 'jsb <braceStyle>' parameter, displayed when the user asks for help
> >  # on what it does.
> > +jsbBraceStyleManual2=Select the coding style of braces: collapse - put braces on the same line as control statements, expand - put braces on own line (Allman / ANSI style), end-expand - put end braces on own line or expand-strict - put brace on own line even if it will break your code.
> 
> I'd recommend to get a copy writer for this like Matej.
> 
> My non-native speaker suggestion would be to use ';' to separate the cases
> consistently (no or for the last one).

Done

Comment 5

[Joe Walker [:jwalker]]

Comment on attachment 669902 [details] [diff] [review]
Updated strings v2

Review of attachment 669902 [details] [diff] [review]:
-----------------------------------------------------------------

I think we need to get bug 799462 landed, so we can get it in aurora fairly soon, so we don't confuse any more translators.
This means that this bug will be bitrotted. r+ nevertheless.

Comment 6

[Joe Walker [:jwalker]]

New component triage. Filter on "Lobster Thermidor aux crevettes with a Mornay sauce"

Comment 7

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Attachment: Rebased

Rebased

Comment 8

[Paul Rouget [:paul]]

https://hg.mozilla.org/integration/fx-team/rev/b824eca042e8

Comment 9

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/mozilla-central/rev/b824eca042e8

Comment 10

[Francesco Lodolo [:flod]]

I think I need a little explanation here

jsbBraceStyleManual2=Select the coding style of braces: collapse - put braces on the same line as control statements; expand - put braces on own line (Allman / ANSI style); end-expand - put end braces on own line; expand-strict - put braces on own line even if it will break your code.

1) My understanding is that collapse, end-expand, etc. should not be translated, since they're parameter values. Am I right? In this case a localization comment should be added to explain it.

2) "even if it will break your code". Breaking the code means that the code is no more functional or something else?

Comment 11

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

(In reply to Francesco Lodolo [:flod] from comment #10)
> I think I need a little explanation here
> 
> jsbBraceStyleManual2=Select the coding style of braces: collapse - put
> braces on the same line as control statements; expand - put braces on own
> line (Allman / ANSI style); end-expand - put end braces on own line;
> expand-strict - put braces on own line even if it will break your code.
> 
> 1) My understanding is that collapse, end-expand, etc. should not be
> translated, since they're parameter values. Am I right? In this case a
> localization comment should be added to explain it.
> 
> 2) "even if it will break your code". Breaking the code means that the code
> is no more functional or something else?

This bug is already landed so I have logged bug 845750 to address your comments.