Problem/Motivation
When installing Drupal in a foreign language, the default site name is overridden with the value provided on install. That is correct. When adding a foreign language, the comparison between the current and shipped value rules out the site name for community translation because the site name is usually different from "Drupal". However following #2212069: Non-English Drupal sites get default configuration in English, edited in English, originals not actually used if translated, comparison of active config values and default values is not possible anymore. So when adding English, the translation is "Drupal" automatically and when adding other languages, the translation of "Drupal" is used.
Proposed resolution
Add "Drupal" dynamically instead of doing it in the default config.
Remaining tasks
Review. Commit.
User interface changes
None.
API changes
None.
Comment | File | Size | Author |
---|---|---|---|
#9 | interdiff.txt | 1.21 KB | Gábor Hojtsy |
#9 | 2457703-9.patch | 6.57 KB | Gábor Hojtsy |
#6 | 2457703-6.patch | 6.24 KB | Gábor Hojtsy |
#5 | interdiff.txt | 5.3 KB | Gábor Hojtsy |
#5 | 2457703-5.patch | 6.4 KB | Gábor Hojtsy |
Comments
Comment #1
Gábor HojtsyLet's see how this fairs :)
Comment #3
Gábor HojtsyAttempt to set the default in system_install() instead, which should always run(?).
Comment #5
Gábor HojtsyYeah it does not matter which trick I use, the tests fail because they either assume a 'Drupal' value in a unit test (install hook did not run) or assume the 'Drupal' value was the default and is translatable. Fixes:
ConfigSchemaTest.php: fix the assumption about the default value.
LocaleConfigTranslationTest.php: make it test the maintenance message because that still has a meaningful default
TokenReplaceUnitTest.php: assumes the Drupal default value with tokens, so set it in setUp.
MigrateFileTest.php: that was an unrelated fail
Comment #6
Gábor HojtsyReroll. Patch did not apply anymore due to #2212069: Non-English Drupal sites get default configuration in English, edited in English, originals not actually used if translated.
Comment #7
BerdirShould we switch to a different key to test this? that doesn't make much sense...
Patch looks fine, that said, I still think that an official notion of "localizable but not translatable" would be great to have for config schema, also TMGMT. Views for example has a lot of weird strings (like ', ') it just doesn't make sense to send them to localize.drupal.org.
Comment #8
BerdirComment #9
Gábor Hojtsy@Berdir: ok, I can remove this whole section of the test. That is probably better than replacing it with testing the maintenance mode setting which we do elsewhere in the test. We don't need to repeat testing the same things so much I guess.
As for the localizability, the site name would still be translatable and values where you may use ',' in Views MAY still contain "and" or similar human language elements depending on the View, right? So we cannot really say outright that it would not be translatable on the config structure/schema level? Anyway, that is not related to this issue.
Comment #10
BerdirThanks, removing seems fine.
Yes, it would still be possible, but that's exactly what localizable but not translatable means to me. It can be changed per language, and our UI would continue to support it in exactly the same way, but translate.drupal.org wouldn't have to bother with it, and it wouldn't provide default translations.
Will test this once more and then probably RTBC it.
Comment #11
BerdirThis works great now. Opened #2462505: Add a localizable but not translatable concept to config schema to explore my idea.
Comment #12
alexpottThis issue is a normal bug fix, and doesn't include any disruptive changes, so it is allowed per https://www.drupal.org/core/beta-changes. Committed ffdfab2 and pushed to 8.0.x. Thanks!
Comment #14
Gábor HojtsyGreat, thanks! I followed up on #2462505: Add a localizable but not translatable concept to config schema in the meantime, let's continue discussing that there. (It does not apply to the site name AFAIS).