(In reply to Magnus Melin [:mkmelin] from comment #4) > Hmm, I think this is an example of incorrect usage of message references. As you had mentioned this before, I had carefully checked this for correct usage. The message reference which you have removed was correct imo, following exactly the document which you mentioned [1]: > **Message References** > [snip] > On the other hand, this approach is helpful if, for example, you want to reference another element of the UI in your message: > ``` > help-button = Help > help-explanation = Click the { help-button} to access support > ``` > This enforces consistency and, if help-button changes, all other messages will need to be updated anyway. I think that's exactly what we want here: We want to *enforce* consistency between the main menu and the app menu strings on menuitems (where applicable), so we are "referencing another element of the UI in our message". The message-referencing cases which should be avoided per documentation are different from our case here. > You can't know the accesskey would always fit in with with the surrounding context, and the everybody would have to update *both* places. Hmmm - I'm failing to see any access key problem here: - The original message in the *main* menu has an access key, which any localization will choose freely according to their needs. - In the *app* menu, we explicitly only reference the main menu message with the menuitem label (sic), not the access key message: ``` appmenu-save-as-file = .label = { menu-file-save-as-file.label } ``` > Not to mention, the app-menu doesn't use accesskeys... Yes, that's why we are referencing only the label-message, not the access key, so no access key is shown on the appmenu (I've just re-tested that). So imho there was nothing wrong with the original solution here. > [1] https://firefox-source-docs.mozilla.org/l10n/fluent/review.html#message-references
Bug 1707434 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Magnus Melin [:mkmelin] from comment #4) > Hmm, I think this is an example of incorrect usage of message references. As you had mentioned this before, I had carefully checked this for correct usage. The message reference which you have removed was correct imo, following exactly the document which you mentioned [1]: > **Message References** > [snip] > On the other hand, this approach is helpful if, for example, you want to reference another element of the UI in your message: > ``` > help-button = Help > help-explanation = Click the { help-button} to access support > ``` > This enforces consistency and, if help-button changes, all other messages will need to be updated anyway. I think that's exactly what we want here: We want to *enforce* consistency between the main menu and the app menu strings on menuitems (where applicable), so we are "referencing another element of the UI in our message". The message-referencing cases which should be avoided per documentation are different from our case here. > You can't know the accesskey would always fit in with with the surrounding context, and the everybody would have to update *both* places. Hmmm - I'm failing to see any access key problem here: - The original message in the *main* menu has an access key, which any localization will choose freely according to their needs. - In the *app* menu, we explicitly only reference the main menu message with the menuitem label (sic), not the access key message: ``` appmenu-save-as-file = .label = { menu-file-save-as-file.label } ``` > Not to mention, the app-menu doesn't use accesskeys... Yes, that's why we are referencing only the label-message, not the access key, so no access key is shown on the appmenu (I've just re-tested that). So imho there was nothing wrong with the original solution here, and it would appear to be superior wrt enforcing consistency. > [1] https://firefox-source-docs.mozilla.org/l10n/fluent/review.html#message-references