No description
Find a file
Marvin Kuhl 7a09493c5d
All checks were successful
ci/woodpecker/push/code-style Pipeline was successful
ci/woodpecker/push/functional-tests Pipeline was successful
Merge tag '1.0.1' into develop
Tagging 1.0.1
2023-09-29 17:34:21 +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
composer.json First version, extracted and tested 2023-08-05 15:58:50 +02:00
README.md Better documentation for the lessons learned 2023-08-08 17:58:13 +02:00

DigiComp.FlowTranslationEndpoint

Build status

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.