If you are using an install profile to customize the installation experience, you'd better be using only strings that core itself uses, because your custom strings will never be translated.
This is because the early installer only ever downloads and reads translations for core. If there's a custom profile in play, its strings are completely ignored.
Drupal CMS runs into this because it uses a custom install profile, and it has to do some very dubious workarounds in order to get its translations loaded in the early installer. This is clearly a bug, because the installer supports custom profiles, and translation, but this scenario falls through the cracks.
install_download_translation() needs to download the profile's translations too! Additionally, \Drupal\Core\StringTranslation\Translator\FileTranslation needs to read translations not just for core, but also for the profile.
TBD
| Comment | File | Size | Author |
|---|
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
phenaproximaComment #3
gábor hojtsyI think this makes a ton of sense. Drupal CMS still still need to custom-download the .po file for the site template recipe chosen so its a shift in how the same code will be used in the CMS installer, but core could still do the profile already, it would make slightly less custom code in the CMS installer :)
Comment #5
phenaproximaComment #6
phenaproximaThis was going to be way too hard to test functionally, so I did it as a reasonably high-level kernel test which confirms that translations are downloaded for custom profiles, but not core profiles.
Comment #7
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #8
phenaproximaAs far as I can tell (and I added more test coverage to confirm this), the version is passed through unaltered.
Comment #9
gábor hojtsy#3594389: Remove unecessary core dev version replacement in locale project info just landed. so much for dealing with the
-devsuffix. Sorry, I was not aware that it works without that removed.Comment #10
phenaproximaThat simplifies things :) Removed the
-devspecial-casing.Comment #11
gábor hojtsyYay, now this looks all good to me :)
Comment #12
quietone commentedComment #13
gábor hojtsyBTW #3529211: The installer should download translations for the current install profile is a duplicate from a year ago that @phenaproxima also worked on. That was the first google result when I searched for this issue :D
Comment #14
alexpottCommitted and pushed e439b183f1d to main and de801c94f79 to 11.x and 1908b48df45 to 11.4.x. Thanks!
Great to see the kernel test for this. Nice one. Backported to 11.4.x and raising to major inline with the duplicate. As far as I can see the API tweaks here are all additions and will not cause breakages in the unlikely event that contrib or custom code is using these functions and classes.
Comment #16
gábor hojtsyAdding 11.5 highlights tag as we can group the profile related improvements compared to 11.4.0 nicely there I think, even if some are bugfixes.