Reorganization of translation keys

Dominion

Yes ... but I am not the Architect, merely the Keymaker! 😉

... Although I do tend to run on like that Architect guy at times ...

Dominion

@Toby , regarding this:

Dominion Is it possible to combine strings?

I think I may have been a bit too optimistic about a couple of reuse instances. Cases in point:

The "Log In" link at the bottom of the signup modal

The "Sign Up" link at the bottom of the login modal

At first glance, these two links look like the other "Log In" and "Sign Up" links/buttons. But they're different in that they come with context, i.e. the core.before_log_in_link and core.before_sign_up_link strings, respectively. Some translators may need the freedom to embed the link in the context sentence, like so:

If you already have an account, please log in instead.

Even if there is no need for non-link text after the link, the hardcoded space separating the link from the context is bound to cause trouble for some translators. So each of these string pairs should be handled as one.

After staring at this for a while, I've concluded that most translators will probably be able to make do with the two existing strings, so there's no need to preemptively merge them with the "before" strings. Let's leave them as they are (with the "before" strings appropriately renamed) until someone really needs this.

However, the hardcoded space between the "before" string and the link could be a problem, so it would be best to move it inside the "before" string. I think I can manage that small a change to the JS on my own, but wanted to check on how it's handled in the YML. Am I correct in assuming that all I'd have to do is enclose the string in quotes, like so:

"Already have an account? "

... with an extra space after the question mark? Or is it going to be more complicated than that?

Toby

Dominion Nope, that's all there is to it 🙂

Dominion

Great! Then that's one less thing to worry about before the big reorganization.

Dominion

@Toby and @Franz :

Okay, I think I'm finally set to get down to actual editing. But first, a quick note on the composer_ chunks:

I think there's more to be gained from grouping them together than from separating them. Putting them right next to each other will enable translators to easily compare the three composer variations and decide how they want to handle the differences. (In many cases they may want to reuse strings, making the variations more similar.)

Compared to that extra convenience, making the prefixes feel more like natural language is really an aesthetic issue; it won't necessarily make them easier to find. (And remember, every chunk will be accompanied by a comment with a natural language description. 😉 )

Here's how I plan to proceed:

Crunch the matrix down into YML file format.
Add comments, and eyeball the entire thing for errors.
Show you the completed YML file for a final check.
Create a new branch and edit in all the new keys.
PR that, and get working on documentation as follows:
- Create a i18n specification for developers, explaining how to name keys.
- Update the l10n specs, to explain string referencing and reuse to translators.
- Create a migration guide to help translators migrate any existing work.
When the docs are ready, get cracking on extension keys.

I figure that if I edit and PR before I start on the docs, it will give you time to devise and test the compiler (and make sure my changes actually work). But if you'd rather see the documentation before I start editing (say, to get a better overview of how it all hangs together) then I can do that too. Just let me know.

Toby

Dominion All sounds good 😃

« Previous Page