Project Proposal: Implementing label overrides and fallbacks in Flow

Motivation

One occasionally runs into cases where labels of other parties' packages have to be overridden, with the most prominent example being the Neos backend. (see https://jira.neos.io/browse/FLOW-61)

Staus Quo

There are a few workarounds for doing this (see https://jira.neos.io/browse/NEOS-1258) that are mostly based on label override / replacement configuration.

Why I consider this un-Neos-y

In the current state, all components (inspector, backend flash messages, modules, you name it) have to define their own configuration how to add or override labels. This doesn't look like fun, neither for developers having to consider implementing such mechanisms with every step they take, nor for integrators who have to set Yet Another Configuration Option™ in addition to providing the labels.

Proposition: how to improve the situation

Flow should provide override capabilities within the internationalization component itself.

Labels are, within the localization context, identified by three properties: the package they belong to, the source path within that package and their id (or value, which afaik is supported but disencouraged).

The current implementation derives package and source from XLIFF file’s position in the file system. This means that the labels one provides in one’s package can never leave that package scope and thus are incapable of overriding anything by themselves.

To improve this, XLIFF’s own structure can come in very handy. If you look at label files, you see some standard fields that have been ignored in the past:

<file original="" product-name="" source-language="en" datatype="plaintext" target-language="de">

The XLIFF specification for original is:

The original attribute specifies the name of the original file from which the contents of a element has been extracted.

This should be close enough to define the source.
Also product-name should do as a package reference:

The name of the product which uses this file.

With something like <file original="NodeTypes/Document" product-name="TYPO3.Neos" source-language="en" datatype="plaintext" target-language="de"> one could easily override the default labels, if Flow evaluates those parameters as an override for package name and file path where the XLIFF file is located. No reconfiguration of anything needed.

Consequences

Since the file path and package name can still be used as a fallback, this should not break anything

tl;dr

Use XLIFF's original and product-name properties as an override for file path and package name of XLIFF files to improve label handling.
1 Like

Thanks for bringing this up, this was the ideal solution but required a more work than could be done as the first phase.

It’s worth adding that such a solution would use the package dependency ordering for the overriding logic, similar to the configuration overriding.


Additionally one point of improvement while working in this area, would be to streamline the translation helpers. Currently the Package:Catalog:LabelId format is only supported in the EEL TranslationHelper and the Neos backend TranslateViewHelper, but not in the XliffTranslationProvider and the Fluid TranslateViewHelper.

There’s probably similar inconsistencies that could use a bit of cleanup.

Thanks for the writeup. @robert and I had just discussed this today… and came to very similar conclusions (and some more related to all kinds of “configuration” overrides).

Your idea combined with the points @aertmann brought up makes this a very nice concept, IMHO!

Now: who does it? :wink:

Well, it’s acually more of a warmup of FLOW-61 :slight_smile:
Could be a nice introductionary task for me. Who would be the respective reviewer / person to ask questions?

Really like that aproach. Might be a bit of work to deal with it inside the XliffModel, as that will need some clever mechanism to avoid loading all translation files for every Model instance to find the overrides, but some clever caching/static compilation could maybe help. I’ll gladly join in on reviewing your PR.

Well, I was mentoring the initial XLIFF work back then… so you might try to ask me, I might remember things…

fyi: PR is here:
https://github.com/neos/flow-development-collection/pull/505

1 Like

I’m resurrecting this because: The Flow 4 compatible PR is open for review!
Could ship with 4.1 but is also compatible with 4.0 if we wanted to add new features to it.

1 Like