Where to store translations – additional localtion?

[ursbraem]

Both storage variants have their problems:

a) extension (you can run into trouble because you overwrite them by pushing)
b) l10n (you can run into trouble because you overwrite them either by typo3cms language:update or clicking in the backend.)

-> what do you think about adding a third location? like l10n_custom? Do you think that would make any sense in regard to the above issues?

PS the robust solution would be to store the translations in the database (it's editor created content) and write the files in the third location automatically....

[nostadt]

We do not have the scenario at which editor / admins overwrite language in the live system but we do it on the local machine as developer.
I personally had not the scenario to translate 3rd party ext.

So can you provide more details on the scenario?

[ursbraem]

I thought that was the purpose of the extension!

[ursbraem]

To give editors power over translations / labels

[nostadt]

Legit.

[nostadt]

After all the languages have to be loaded by TYPO3. So simply saving them at an arbitrary location won't do much.

Storing them in the database sounds nice too. In my opinion it should be sth. like this:
https://jweiland.net/typo3/beispiele-anleitungen-faq/typoscript/texte-in-extensions-updatesicher-anpassen.html

## Default Text = Englisch
plugin.tx_indexedsearch._LOCAL_LANG.default {
  form.searchFor = Search for:
  form.submit = Search
  result.noResult = No results!
}

## Deutscher Text
plugin.tx_indexedsearch._LOCAL_LANG.de {
  form.searchFor = Suche nach:
  form.submit = Suchen
  result.noResult = Keine Suchergebnisse!
}

Yet there are a few things to be considered.

• How should the ext. determine whether a key belongs into the XLF file or the database
• does the above TS cares about XLF files? How can I address my_custom.xlf.
• should there be a custom TS template which has to be included once by an admin

[ursbraem]

A little preamble:

The thing with versioning and deployment workflows ist:

• Content (everything you can manage through the CMS) should be stored in the database and not be versioned
  Content is synced in the direction Prod > Staging > Local ("down")

• Code should be stored in the code and be versioned
  Code is synced the other way round ("up")

So it has become a best practice to take out TS from the "Info/Modify" module and include it from the code.
Localisation falls in between the cracks somehow in most CMS. Labels are always stored in language files in the code.
A reason seems to be performance?

I have a knack for workaroundish thinking. My idea was: what if TYPO3 would WRITE the complete XLF files ad hoc (on change) into the (somewhat ephemere, because it can be updated with a single click in the backend) l10n folder?

So we would have a translation table:

tx_translate_locallang_domain_model.translation

There, you maybe have

key = foo
de = Foh
fr = Feu
en = Fou

etc. or handle the "elasticity" of languages with a json (one field for all translations). Just store it in the db as the final source. Whenever a value is changed, the xml files in the (unversioned) l10n folder is written fresh and cache is cleared)

From where it is processed as usual.

-> that's my idea.

But: maybe you now say: why not just use a translation server ? That is already how that works! – If so, the reason is simply that I don't understand how that would work and how we could give editors access to translations via a server without spending a fortune. Maybe you can help me there? Then the use case for the extension could be reduced to what you initially stated (a developer tool)

[nostadt]

In general I have thoughts for some of the aspects you mention as well as agree overall, but I have no ideal solution. So I skip these thoughts.

Things you could ask yourself and perhaps the customer:

1. What kind of translations the editor would need to adjust and how often?
2. Do they probably fit more into a plugin or a database record. For example address which you can then render in the footer to display the company address

While I am not a big fan of implementing a database table including domain model etc. just for one record it could be a solution to allow editors to maintain certain site-wide data. Doing it this way allows you to make use of the access management either.

[ursbraem]

The location is correct, it's about labels and stuff. But they are translated and modified quite often.
Maybe you have an idea what other I could use instead of translate_locallang to maintain the XLFs as described? I mean, something like https://translation.typo3.org/ with a GUI but private?

[kitzberger]

I'd prefer a separate folder on the filesystem as well and genuinely dislike the idea of writing them into the DB. On the other hand would the latter make it possible to have different translations on different page trees. Tempting 🤔

Our scenario is the following: admin users should be able to tweak the translation labels on production without having to bother the devs. The separate folder could be automatically version-controlled with a separate git repo by a cron job.

[nostadt]

I'd prefer a separate folder on the filesystem as well and genuinely dislike the idea of writing them into the DB. On the other hand would the latter make it possible to have different translations on different page trees. Tempting 🤔

Our scenario is the following: admin users should be able to tweak the translation labels on production without having to bother the devs. The separate folder could be automatically version-controlled with a separate git repo by a cron job.

To me it sounds like it will be quite some work with a separate git repository. Something you have to consider at least is that some changes may not be committed:
Say the cron job is executed every 5 minutes but a value has been changed twice. While this may not be an issue it should be IMO considered. The other issue is what commit message to choose which is relevant in case rollbacks might be desired. If it's simply the current date and time it is pretty useless. If you do I would consider to add the changed files / paths to the commit message body.

[kitzberger]

@AMartinNo1, in my considerations it's a cronjob running only once a day. Like a backup kinda mechanism to prevent the backend users from accidentally deleting everything ;-)