Rename traits to attributes and change syntax

[stasm]

Goal

Provide easier syntax for multi-valued messages.

Description

While #5 is about multiple facets of the same value, this is about multiple values. This is useful in case of web components or other UI widgets.

Currently we'd write:

key = Value
  [label] Label

This looks similar to a variant of a select-expression but actually defines a trait and "Label" is a separate value, one of two values of the key message. When #1 is fixed this will become even more confusing, because lists of traits will not require defaults, but will use the same syntax as lists of variants.

The proposed solution is to use . (the dot) as a new syntax for defining traits. Also, to better reflect their purpose, we want to rename traits to attributes.

key = Value
key.label = Label

If there is no value it's definition can be omitted:

file-open.label = Open File
file-open.accesskey = O 

This will also require an addition of attribute-expression:

attribute-expression ::= identifier '.' keyword;

file-open.label = Open File
file-open.accesskey = O 
file-open.title = To open an existing file press Ctrl + { file-open.accesskey }.

Discussion

https://groups.google.com/forum/#!topic/mozilla.tools.l10n/dhWfBXHzuZI

[Pike]

The repitition of the base ID is tricky for developers changing strings. We had this in our current strings, when developers would change label, and screw up accesskey, etc.

I expect that repitition to be a source of grief in practice, both when writing messages from scratch and getting copy-n-paste wrong, as well as editing strings to update to new content.

In the newsgroup, there's an alternative compressed version,

file-open
  .label     = File Open
  .accesskey = O 

That looks OK to me.

[stasm]

The repitition of the base ID is tricky for developers changing strings. We had this in our current strings, when developers would change label, and screw up accesskey, etc.

That's a great point. I did not consider that.

I too like the syntax @Pike suggested in his comment. That said I am a bit concerned about the edge-cases, like messages with just one attribute:

file-open
    .label = Open File…

…or messages or attributes with complex values:

preferences-open
    .label = { PLATFORM() ->
        [windows] Open Settings
       *[other] Open Preferences
    }
    .accesskey = { PLATFORM() ->
        [windows] S
       *[other] P
    }

I find them okay to read but would like to spend some more time thinking about this.

[stasm]

Or combinations of message values and attributes:

preferences-help = Click the Gear button in order to change your { PLATFORM() ->
    [windows] settings
   *[other] preferences
}.
    .title = The Gear button can be found in the upper-right corner of the UI.

or:

preferences-help = 
    | Click the Gear button in order to change your { PLATFORM() ->
        [windows] settings
       *[other] preferences
    }.
    .title = The Gear button can be found in the upper-right corner of the UI.

(I have doubts if | was the right choice for multi-line strings precisely because of how it's used in combination with select expressions. That's a topic for another discussion however.)

[zbraniecki]

like messages with just one attribute:

Can we support both:

fileMenu.accesskey = Foo

and

fileMenu
  .accesskey = Foo

?

[stasm]

I think we could, but I'd also prefer to start with only one version. Let's go ahead with

lipsum
    .label = Lorem

for now.

[stasm]

@Pike made a point that allowing a condensed syntax of the lipsum.label = Lorem form might lead developers to believe that they can request lipsum.label from the source code. Given that, it's probably better to not allow it at all.

Also, in order to allow an introduction of an attribute-expression which can be used to reference attributes from placeables (foo-help = Press { foo.accesskey }), we will need to forbid dots . as allowed characters in the identifier.

[zbraniecki]

@Pike made a point that allowing a condensed syntax of the lipsum.label = Lorem form might lead developers to believe that they can request lipsum.label from the source code.

This is not our experience from working with devs on FxOS.

I'm fine with going for the enforced new line, but I don't believe that the concern is warrant given that devs have been doing it with .properties files for a couple years in FxOS without a problem.