Still waiting to hear if we're doing some special for macOS, but until then, we'll presume conversion across platforms.

macOS says title casing: https://developer.apple.com/design/human-interface-guidelines/macos/menus/menu-anatomy/
Gnome says "header capitalization" which is similar to title casing: https://developer.gnome.org/hig/stable/writing-style.html.en
KDE also says title casing: https://hig.kde.org/style/writing/capitalization.html

Seems to me that this ought to apply only to Windows.

Thanks, Asif. We're taking the guidelines from Apple, Gnome and KDE here as recommendations. Our copy specialists, who are aware of these recommendations, are going to make the final call on what type of casing we'll use and where.

Mike, it doesn't seem like there is a great reason to break the guidelines here - and while I realize that Proton is a new thing, this is anti-Photon and not in line with being a good platform citizen.

Just expressing my disapproval as a rule here. Appreciate all you and the teams do for Firefox!

Disapproval heard, thanks!

Having reviewed the landscape across each of the supported desktop platforms, we're going to not include the main menubar in the effort to converge to Sentence case. Items in the menubar should be in Title Case.

As we migrate more strings to Sentence case, we should ensure we don't accidentally modify any of the strings in the menubar. This bug is now to add a test ensure we maintain Title Case in the menubar.

We've converged on having the menubar use Title Case, but menus supplied from the toolbar (like the App Menu) use Sentence case.

Small pickle here - some strings are shared between these two context. For example, the Web Developer menu is accessible both via the menubar (Tools > Web Developer) and the App Menu.

I'm trying to determine what the simplest way of dealing with this would be. A few options come to mind:

1. The naive solution is to fork the strings and use distinct strings in the menubar vs everywhere else. We could use Fluent Migrations to avoid having our localization community have to re-create strings for the new menubar-specific entities (or items that would be switched off of the menubar strings).

2. Use a selector for a string based on its context. Something like:

menu-tools-web-developer =
    .label = { $context ->
      [menubar] Web Developer
      *[other] Web developer
    }
    .accesskey = W

and then make sure that the menuitem node in the menubar uses something like this:

<menu id="webDeveloperMenu" data-l10n-id="menu-tools-web-developer" data-l10n-args="{context: 'menubar'}">

This would require us to parse JSON for each menuitem node that uses this technique, however. A potential for performance trouble.

3. Programmatically ensure that strings are using Title Case in the menubar via some Fluent API that we'd need to define. According to the APA style guide for English, Title Case means capitalizing everything except words like these:

    short conjunctions (e.g., “and,” “as,” “but,” “for,” “if,” “nor,” “or,” “so,” “yet”)
    articles (“a,” “an,” “the”)
    short prepositions (e.g., “as,” “at,” “by,” “for,” “in,” “of,” “off,” “on,” “per,” “to,” “up,” “via”)

in theory... in English locales, we could uppercase everything except those words at run time? This also makes me a little nervous, both from a performance standpoint, and the fact that we'd be putting English-specific codepaths in the browser code.

Any suggestions, flod / gandalf / gijs?

(In reply to Mike Conley (:mconley) (:⚙️) from comment #6)

1. The naive solution is to fork the strings and use distinct strings in the menubar vs everywhere else. We could use Fluent Migrations to avoid having our localization community have to re-create strings for the new menubar-specific entities (or items that would be switched off of the menubar strings).

This seems like the least painful option. The upside is that our sharing of access keys when reusing items including l10n strings was a bit of a pain anyway, and so in a sense the duplication is Right there anyway. The duplication is also not as bad as it may seem for localizers that use Pontoon because it'll suggest translations based on identical strings elsewhere.

in theory... in English locales, we could uppercase everything except those words at run time? This also makes me a little nervous, both from a performance standpoint, and the fact that we'd be putting English-specific codepaths in the browser code.

Building an analogous models for each locale would be a significant engineering effort and may be even impossible. Hence my question - if we want to explore such avenue, I'd like to research existing internationalization databases for title casing and APIs to use them.

Also, I hope the UX is not suggesting enforcing title casing in locales where culturally title casing is not accepted (like Slavic languages, where title case model just doesn't exist at all).

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #8)

Also, I hope the UX is not suggesting enforcing title casing in locales where culturally title casing is not accepted (like Slavic languages, where title case model just doesn't exist at all).

Yeah, this is only for English locales. Absolutely we don't want to try changing the case for languages where it doesn't apply or make sense.

I would definitely go with 1, and use Fluent migrations to mitigate the impact (risk of losing translations). We also need to figure out if migrating affected DTD strings to Fluent is in scope (I'd really like to avoid adding new DTD strings).

Strings being shared in different contexts is not ideal, especially when they have accesskeys, so splitting would solve two problems in one go.

@zibi
Did we ever end up making a performance analysis for Fluent UI with a lot of selectors? I remember conversations around using PLATFORM() to ship one Japanese localization, and measuring the performance, but I couldn't find a bug anywhere.

Did we ever end up making a performance analysis for Fluent UI with a lot of selectors?

I don't think we did, but I just run a little back-of-the-envelope benchmark on a local laptop:

For scale, I started by just formatting 100 compound messages in browser console: ~900us.
I expect bulk of it to be Rust->JS, XPCOM, struct allocation etc.

Next, I tested https://github.com/projectfluent/fluent-rs for simple.ftl (100 simple messages) vs simple2.ftl (100 messages with a selector): 4us -> 12us.

So, while in the first part I formatted compound messages (each message had ~2 attributes), and some of them had variables etc., my initial guess is that the difference between selector and lack of selector should account for no more than 10/900 = 1% of the total time of formatting.

If you'll need more detailed evaluation, I can take the simple.ftl/simple2.ftl into the browser and test again.

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