Contrib.social

Don't consider locale fallbacks while editing translations

Open on Drupal.org →
Created on 15 March 2021, about 4 years ago
Updated 29 January 2025, 2 months ago

Problem/Motivation

\Drupal\language_hierarchy\StringDatabaseStorageDecorator::dbStringSelect() currently is also applied when searching for translations in the backend, causing some really weird effects.

The whole trick with the ordering and joining the hierarchy table falls flat if you don't query for a single translation because if you have multiple results then you really have no idea what is actually going to happen.

One way to detect that would be hardcoded pager limit option passed in in \Drupal\locale\Form\TranslateFormBase::translateFilterLoadStrings().

PS: StringDatabaseStorageDecorator is not a decorator. You can't decorate protected methods, you can only decorate public methods and it is only decorating if you are actually passing all calls to the inner service. Which you are not, __call() would only be called if a method is *not* defined, otherwise you just completely replace the inner service. You can't use __call() to decorate a service with an interface because you must explicitly implement each method. I think service decoration is heavily overrated and in most cases not correctly done. But that's beside the point there. Should just be honest about it and replace the service class :)

Steps to reproduce

Add a translation, switch to another language, get wrong translations back as the translation of that language.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

✨ Feature request
Status

Needs work

Version

2.0

Component

Code

Created by

🇨🇭Switzerland berdir Switzerland

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment 2 months ago →
    🇩🇪Germany ktpm

    Not sure if I should post this here or in #3188336: Updates to string causes over-write of fallback language → as both are related, but since this issue is still open, let's go with this.

    Currently, if you try to import translations to a language, which has parent languages, the translations of the parent language may be overridden, when using drush locale:import with any --override option. This happens, if there is no string item for the target language yet. This probably also occurs when using the import form in the backend, but I did not explicitly test it that way.

    Example:
    EN as parent language
    Set any language as child language, like DE.

    How it happens:
    - The StringDatabaseStorageDecorator::dbStringSelect() wants to retrieve fallback candidates for the db select.
    - The candidate selection is done in the language_fallback_candidates_alter hook. EN is returned as candidate.
    - DE & EN are passed to the db select. String item for DE does not exist, hence the query returns the EN item.
    - PoDatabaseWriter::importString() SHOULD go to the else part ("No such source string in the database yet.") but gets EN string.
    - Because override option is set, string item gets overwritten/updated.

    As the candidate selection part is done in the alter hook, I believe the check should be done there, as I did in the attached patch file. Not too sure about it though. So I added some checks there if the current process is being run via cli (drush), if there is an actual batch being processed, and if the batch is a locale translate import, to be as specific as possible about this. There may be better ways to do this, but it helped me to avoid this issue.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024