@Toby and @Franz ... just a couple quick updates to keep you apprised of my progress.
I've gone through about one-fifth of the strings, devising unique key names for each and making note of global references where needed. My thinking about key names has been evolving a bit during this process, so I thought you'd want to know how things are shaping up.
Regarding globals:
As I suspected, the global strings will all use their existing key names. Not only are they all short and descriptive enough, they will also be cross-referenced back to the unique keys that reference them, so there's no need to make them any more complicated.
Regarding prefixes:
For the most part, I'm trying to stick with prefixes that are similar to the JS filenames, which tend to describe the location where strings are used well enough. But there are some cases where a bit of rearranging seems in order. For example, there are four JS files related to the composer:
- Composer
- DiscussionComposer
- EditPostComposer
- ReplyComposer
It might be useful to translators to group these together, so I'm using a general-to-specific scheme for prefixes:
- composer_
- composer_discussion_
- composer_edit_
- composer_reply_
I was afraid this might become too cumbersome, but so far it seems to be working out well enough.
Regarding suffixes:
Since we're going with unique key names, it occurred to me that the suffixes could be a bit more detailed (and therefore descriptive). For example, you had suggested "_action" as a suffix for things like buttons, links, etc. That was fine when a single key had to cover multiple uses of the same string. But unique keys give allow us to give translators more intuitive descriptions of how a string is used. If it's a button, we can call it a button.
This means the list of suffixes will get a bit longer, but I don't think it will be any less consistent. And ultimately developers may find it easier to use suffixes that are less abstract and closer to natural language.
