Packages

Go to file

Marvin Kuhl 775d597058 ci/woodpecker/push/code-style Pipeline was successful Details ci/woodpecker/push/functional-tests Pipeline was successful Details Merge branch 'release/1.0.1'		2023-09-29 17:34:04 +02:00
.woodpecker	adjust to woodpecker v1.0	2023-08-15 14:19:25 +02:00
Classes	returns an array if there are multiple to be able to handle plural forms	2023-09-29 17:29:30 +02:00
Configuration	As the tests shown, that the custom parameter breaks browser based caching, we now enforce the 'traditional url' approach and added cache control information for the browser	2023-08-08 17:02:13 +02:00
Resources/Private/Translations	First version, extracted and tested	2023-08-05 15:58:50 +02:00
Tests/Functional	As the tests shown, that the custom parameter breaks browser based caching, we now enforce the 'traditional url' approach and added cache control information for the browser	2023-08-08 17:02:13 +02:00
README.md	Better documentation for the lessons learned	2023-08-08 17:58:13 +02:00
composer.json	First version, extracted and tested	2023-08-05 15:58:50 +02:00

README.md

DigiComp.FlowTranslationEndpoint

This package is designed to help bringing needed translations to javascript components, without pushing them to the DOM in your views.

Other solutions, which would generate files available for usage in client scope, have the disadvantage that one would have to repeat the relativ complex overriding and merging logic of Flow. With this endpoint you can get the same content, as you would get, if you call the translation service with your translation id.

The main components are a CurrentHtmlLangViewHelper, which is intended to be used to fill the lang attribute of the html tag, so the frontend knows, which language is currently active (and is good practice anyway) and a TranslationRequestMiddleware, which will respond to any request, where the request path equals DigiComp.FlowTranslationEndpoint.reactOnPath (Default: "/xliff-units"), and search for unit patterns in the DigiComp.FlowTranslationEndpoint.getParameterName (Default: "idPatterns").

"idPatterns" is built with following syntax: packageName:catalogName|SEARCH_REGEX, ANOTHER PATTERN...

For example:

GET /xliff-units?idPatterns=Neos.Flow:Main|authentication.*

would return all translation keys from the main unit of Neos.Flow starting with "authentication" and would look like that:

{
    "Neos.Flow:Main": {
        "authentication.required": "Authentication required", 
        "authentication.username": "Username",
        "authentication.password": "Password", 
        "authentication.new-password": "New password",
        "authentication.login": "Login", 
        "authentication.logout": "Logout"
    }
}

To let the middleware know, in which langauge the translated units should be, you should set the correct Accept-Language-Header with your request, which you obtained from the lang attribute of the html element.

Given your HTML head looks like that:

<html lang="{translation:currentHtmlLang()}" data-xliff-uri="{translation:uri()}" data-xliff-parameter="{translation:parameterName()}">

Your JavaScript could look like that:

async function translate(idPatterns) {
    const uri = new URL(document.documentElement.dataset.xliffUri, document.location);
    uri.searchParams.set(document.documentElement.dataset.xliffParameter, idPatterns);
    const response = await fetch(uri, {headers: {
        'Accept': 'application/json',
        'Accept-Language': document.documentElement.lang,
    }});
    if (! response.ok) {
        return Promise.reject('Unexpected server response');
    }
    return await response.json();
}

Last but not least: Do not forget to have a lot of fun.