[Translator] Move the `var/translations` folder in the `build_dir`

[smnandre]

Currently, UX Translator bundle uses the var/translations directory

When warming up the Symfony cache, all of your translations will be dumped as JavaScript into the var/translations/ directory. For a better developer experience, TypeScript types definitions are also generated aside those JavaScript files.

https://symfony.com/bundles/ux-translator/current/index.html#usage

Directory not found / not writable

But this directory is no standardized, and is not "buildable" (as the ... build directory).

And... this directory is not created by the the Kernel (it does it for cache_dir and build_dir)

It may be then created during cache:warming but for most of the standard deployment tools, any folder not explicitely marked as writable is not..

And so this happens: (folder not writable)

W: + mkdir var/translations
W: mkdir: cannot create directory ‘var/translations’: File exists

And this happens (asset not found)

  W: 11:36:57 WARNING   [asset_mapper] Unable to find asset "../translator" imported from "/app/assets/controllers/translator-demo-controller.js". Try adding ".js" to the end of the import - i.e. "../translator.js".

Use the build dir ?

For me the best choice would be to use the build_dir.

There are other individual solutions, but the build dir is made for this and would remove any future problem too.

So my question is... ..... can we do it or is this a BC ? And..... how ? (as it's currently in the importmap of people)

[kbond]

I think we need to deprecate/remove the config for dump_directory. Unless I'm misunderstanding something, customizing this value would break your app as var/translations is hard-coded elsewhere.

as it's currently in the importmap of people

Is the importmap updated when updating the package?

[smnandre]

Not sure... and it's mainly a webpack bundle so we need to handle multiple install / migration path.

And in the same time i'm thinking "no one came to raise this issue so .... maybe no hurry"

[WebMamba]

Friendly ping to @Kocal since the translator is your baby 😁

[Kocal]

Hi everyone,

The dump_directory was introduced to be independent from the Kernel environment, because in your JavaScript you don't want to import translations from var/cache/dev/translations or var/cache/prod/translations or whatever is your environment. It would be painful to have dynamic paths, so var/translations was the best option here.

Folder var/translations is defined:

• in the recipes https://github.com/symfony/recipes/blob/main/symfony/ux-translator/2.8/assets/translator.js#L11-L16
• in the documentation: https://symfony.com/bundles/ux-translator/current/index.html#installation & https://symfony.com/bundles/ux-translator/current/index.html#using-with-asset-mapper

However I understand your point, but we need a writable/buildable directory that will always be the same whatever your Kernel environment is.

[smnandre]

It is in the documentation, the problem is in this paragraph

When warming up the Symfony cache, all of your translations will be dumped as JavaScript into the var/translations/ directory.

This is not true as nothing is done to create the directory and as we've seen is (one of) reason we had a little bug (nothing dramatic here).

And we should not expose this as configuration now it's hard-coded

$ sf debug:config ux_translator

Current configuration for extension with alias "ux_translator"
==============================================================

ux_translator:
    dump_directory: /Users/simon (... ) .symfony.com/var/translations

Concerning the "shared" directory, i totally understand why this was acted :)

In the futur we probably will have to find a way around this if we want to lower the file sizes, as the enabled locales would depends on the environment.

[Kocal]

This is not true as nothing is done to create the directory and as we've seen is (one of) reason we had a little bug (nothing dramatic here).

The folder var/translations is created by the TranslationsDumper by using Filesystem#mkdir() which creates directory recursively.
It should create var (if not existing) then var/translations (if not existing either), so... maybe am I missing something? 😅

However yes, I don't know why I've made this dump_configuration configurable.. maybe for flexibility? 🤔

[kbond]

I don't know why I've made this dump_configuration configurable.. maybe for flexibility?

I think when using encore, nothing is hard-coded. I think it's just a problem with asset-mapper (whose support was added later)?

[Kocal]

When using webpack Encore (or any bundlers in general), you can import translations (and other functions) from whatever directory you want.

For AssetMapper, given the documentation it looks configurable too:

// importmap.php

'@app/translations' => [
    'path' => 'var/translations/index.js',
],
'@app/translations/configuration' => [
    'path' => 'var/translations/configuration.js',
],

[smnandre]

I don't know why I've made this dump_configuration configurable.. maybe for flexibility?

I think when using encore, nothing is hard-coded. I think it's just a problem with asset-mapper (whose support was added later)?

I think too, but mainly i'm not accusing anyone of anything here, really <3

i'm looking towards a maybe more "standardized" path :) (with no urgency)

[Kocal]

I think too, but mainly i'm not accusing anyone of anything here, really <3

Yeah don't worry, I don't take it personally! :)

So, to resume:

• dump_directory is var/translations by default and can be configurable
• when using Webpack, you can choose to import translations from var/translations or from another directory
• when using Importmap, you can choose to import translations from var/translations or from another directory
• the dump directory should not be kernel's environment dependant
• the dump directory is created by the TranslationsDumper, executed when the Symfony cache is cleared

What can we do to fix your issue?

[smnandre]

I must admit i did not manage to configure / change it :(

Just tried to change "translations" into "translations2"

# config/packages/ux_translator.yaml
ux_translator:
    # The directory where the JavaScript translations are dumped
    dump_directory: '%kernel.project_dir%/var/translations2'

// importmap.php

    '@app/translations' => [
        'path' => 'var/translations2/index.js',
    ],
    '@app/translations/configuration' => [
        'path' => 'var/translations2/configuration.js',
    ],
    

Then called cache clear and importmap install

An exception has been thrown during the rendering of a template ("The asset "var/translations2/index.js" cannot be found in any asset map paths.").
 ("The asset "var/translations2/index.js" cannot be found in any asset map paths.").

Then updated translator.js to replace translation with translations2 too, with no more success

(I'm trying on the ux.symfony.com website)

If this can work, anyone could set its directory depending its own deployment requirements, that would close this issue indeed.

So if you can found the step i must have missed / not done right that'd be the best help you could give me :))

[Kocal]

Did you dump the translations again, by clearing the symfony cache?

[smnandre]

Yep, everytime :)

The translations are dumped in the translation2 directory, that is a good step :)

But then it seems something else is missing in my attempt..

    '@app/translations' => [
        'path' => 'var/translations/index.js',
    ],
    '@app/translations/configuration' => [
        'path' => 'var/translations/configuration.js',
    ],

I tried translations2 in the key, the path, both.. same thing for the path used in the translation js file in assets... I'm sure this is not far away :)

[Kocal]

Mmmh... Unfortunatelly I'm totally not a ImportMap expert, but is there a cache to clear to take importmap.php changes into account? :/