search

FriendsOfTYPO3 / rtehtmlarea

Further maintenance of the HTMLArea RTE, previously part of the TYPO3 Core
https://typo3.org/
GNU General Public License v2.0
9 stars 19 forks source link

Localization lost since version 8.7.x #33

Open responseinformationsdesign opened 5 years ago

responseinformationsdesign commented 5 years ago

Since version 8.7.x the user interface of the editor is just english as the typo3 translation server only delivers language files for the settings in the extension manager.

dmitryd commented 5 years ago

Probably related: #25

dmitryd commented 5 years ago

Problem is not with the extension but with the translation pack on the translation server.

Here is how rte language files structure looks like in the extension:

rte_is_0

Here is how translation pack looks like when fetched from the translation server:

rte_is_1

rte_is_2

Here is how it should look like (and works if I move directories & rename files like that):

rte_should

I do not think how this can be fixed in the extension. Most likely it has to be fixed on the translation server.

xperseguers commented 5 years ago

The problem is that this extension is not a system extension anymore! I wonder though why it is packaging for version 8 then.

Once understood I will have to fetch it from TER instead, just as usual extensions. And this will give possibly some work to try to recover translations from before. And it will live twice in system, once as a system extension, once as a standard extension...

xperseguers commented 5 years ago

OK, filemapping with TYPO3 v8 was created long ago before it got extracted to TER. It was never updated since then.

xperseguers commented 5 years ago

We now have a fundamental problem! Version-specific l10n package is supported since TYPO3 v7 and thus naturally only for system extensions.

Now, since this is not a system extension anymore, we need to drop the version information from the package name (see https://translation.typo3.org/l10n_ter/r/t/rtehtmlarea-l10n/). But this means that the target package name will effectively override the support for TYPO3 v6 and based on the order of preparation of those zips, we will end up having either the zip for TYPO3 v6 (if sysexts are packaged after normal exts) or the zip for the version from TER, which will break TYPO3 v6 (or even former) updating the language packs.

xperseguers commented 5 years ago

I currently see only one solution! And this is implementing the TYPO3 hook which allows to override the URL where to fetch a translation pack. I implemented it back then in order to support 3rd-party localization servers. Here this should be implemented in the version from TER and look for another zip scheme, which I will need to generate differently for that specific extension.

Since it only targets TYPO3 v8 (https://extensions.typo3.org/extension/rtehtmlarea/), it seems logical that the hook should look for a .v8.zip package and the packaging script should be adapted for that extension so that it creates this package instead of a standard zip without version.

What do you think?

BTW: same problem happens/will happen with any other former system extension extracted to TER...

tmotyl commented 5 years ago

@xperseguers can't we add the LL files here directly in the repository as a PR?

xperseguers commented 5 years ago

@tmotyl that's of course a solution, but this means you include the current state of localization for basically all 50 languages and then you either need to update if needed or consider localizations blocked and never updated again. And the project on Pootle stays and still works for TYPO3 up to v7.