Feature: default subKeys

[maranomynet]

I've found this to be very useful - since it allows incrementally upgrading plain translation strings to subkeyed objects, without requiring rewrite of existing code which may rely on the original simple translations.

It also allows less/looser normalization of translation objects, which leads to less need for pointless repetition/verbosity for users maintaining/editing translation files.

This closes the circle on the feature where subkeys are ignored for plain-text translations 08c36f6

This change has slight impact on raw performance (isObject check for all translations), but the added power/flexibility far outweighs it IMO.

---

Given these translations:

var langA = {
  saveButton: 'Save',
  cancelButton: {
    '*': 'Cancel',
    tooltip: 'Cancel all the things \ö/'
  }
}

var langB = {
  saveButton: {
    '*': 'Save all the things!!',
    label: 'Save',
  },
  cancelButton: 'Cancel'
}

var keys = Math.random() > .5 ? langA : langB
var t = translate(keys)

All of these work equally well:

t('saveButton')
t('saveButton', 'label')
t('saveButton', 'tooltip')

t('cancelButton')
t('cancelButton', 'label')
t('cancelButton', 'tooltip')

[maranomynet]

If you agree with this feature, then it would be great if we could merge it quickly and publish a new version

[StephanHoyer]

Seems too much magic to me. Why not use aliases in this case?

var langA = {
  saveButton: 'Save',
  'saveButton:tooltip': '{{saveButton}}',
  'saveButton:label': '{{saveButton}}',
  cancelButton: 'Cancel',
  'cancelButton:tooltip': 'Cancel all the things \ö/'
  'cancelButton:label': '{{cancelButton}}',
}

var langB = {
  saveButton: 'Save all the things!!',
  'saveButton:tooltip': '{{saveButton}}',
  'saveButton:label': 'Save',
  cancelButton: 'Cancel',
  'cancelButton:tooltip': '{{cancelButton}}',
  'cancelButton:label': '{{cancelButton}}',
}

I imagined the dynamic subkeys as a helper to not have to do this

// don't
t('foo:' + bar)
// do
t('foo', bar)

[maranomynet]

Aliases add more work/verbosity, not less, for editors/maintainers in the use cases I'm looking at.

Some thoughts (as I'm still digesting this)...

We already have automatic fallback for non-existent subkeys to a plain-text translation - in cases where the translation has no subkeys at all.

This change adds a single explicit way to declare fallbacks for non-existent subkeys generally – i.e. also in cases where the translation is an object with (some, but not all) subkeys.

So from a library user's perspective this shouldn't add much more magic than they feel is there already.

---

My use cases include a fairly long list of translation keys, that are 95% of the time just a plain-text string. However there are a few different types of variations that are only required for a few of them (like "abbreviated" form for a couple of outliers) and/or are only required in a single language (i.e. context-sensitive grammatical form/declination).

I'm looking for a way to avoid having to normalize all the translations, either on the human-editing end, or by having to write a custom preprocessor for each type/group of translation keys.

My hesitation/laziness wrt writing a case-by-case-basis preprocessor was mainly triggered because doing this at runtime seemed to fit kind of neatly in with what is already happening, it runs very fast, and requires only a minimal change to the library.

---

However, I am very much aware of my own objections to adding magic and feature bloat.

I'm going to think about this over the weekend

[StephanHoyer]

Any findings? If not I would close that

[maranomynet]

I still find this feature an appealing idea.

One thing I just realized is that this also perfectly mirrors the magic wildcard n key for numerical count subkeys. Again a way to view this as a logical extension.

However I think the magic default subkey should be named * instead of __.
That way the meaning is more obvious when reading a translation file/object.

[StephanHoyer]

I just ran into a case, where I need this :D

So if you want to rebase this on current version I would merge it and release a new version.

I'm happy with *

[maranomynet]

Great. Will do later today.
I'm torn between __default__ (obvious) and * (short and wild-cardish), but since * gets your vote, lets go for that.

[maranomynet]

I reverted (reset) the __default__ change and suggest we just merge this as is