Standardised language keys

julian

Up until today, we had a sort of "pseudo-standard" for our language keys. You'd have individual files for different parts of the site (e.g. topic, admin-dashboard, etc.), and within, you'd have language keys that mostly followed some kind of structure: (sub-)classifications divided by periods, followed by the id, e.g...

{
  ...
  "mark-unread.success": "Topic marked as unread.",
  ...
}

Variations were all over the place, sometimes we used dashes, oftentimes we used underscores, and in one case, we used camel case.

So @baris decided to standardize it a bit, and all of the language keys are now dash-separated.

This is also now enforced via test, so language keys may now only contain lowercase latin characters, numbers, a dash, or a period.

This is only enforced for NodeBB core. Plugins and themes can add their own language strings using whatever formatting they prefer.

brazzerstop

Q1
Why was this done? Does this somehow improve the speed of Nodebb? Now less resources are consumed? Messages are loaded faster when language keys were renamed from _ in -? There will be no more sagging when moving from one topic to another?

Q2
So now I need a manually edit all 223 keys to replace _ to - in my custom theme or Nodebb will be support ex-standantizations language key?

julian

You can do whatever you'd like in your custom theme (if they're new keys), although if you're overriding existing keys then yes, you'll want to replace all the underscores with dashes.

<baris>

There will be no more sagging when moving from one topic to another?

What sagging?

oplik0

@baris said in Standardised language keys:

There will be no more sagging when moving from one topic to another?

What sagging?

The key separators were raised so it should take longer until they sag below their lines

Why was this done? Does this somehow improve the speed of Nodebb? Now less resources are consumed? Messages are loaded faster when language keys were renamed from _ in -? There will be no more sagging when moving from one topic to another?

But more seriously - this is probably mostly about removing some tech debt and actually establishing norms for development of (core) NodeBB. Is there a direct positive effect on NodeBB instances? No. But it can help with an issue one may encounter during development (translation key naming - and remember than naming is one of the hard things in computer science).

Is it a huge change? No. But the effect is very limited (only overrides and the only result is using the default instead of the override). One may argue that it's not worth it, but that's a different argument than there being no reason for this change.

brazzerstop

<baris>

@brazzerstop Thanks for reporting fixed in https://github.com/NodeBB/NodeBB/commit/bda37ac27f11ba5dfba4e78d08144c1031696f61