There was some suspicion that not all core configuration strings are found with the potx parser. Eg. some views portions, etc. To verify that I did the following:
1. Installed Drupal 8 RC3 locally.
2. Installed all the core modules.
3. Added a foreign language.
4 Run this query on the DB (output attached):
SELECT name, sid, source, context FROM `locales_location` left join locales_source on locales_location.sid = locales_source.lid where type = "configuration"
5. Downloaded Ukrainian translation (the .pot export of RC3 is timing out on localize and the Ukrainian team is 100%, so they were a good test).
6. Ran this simple script on them:
$translation = file_get_contents('drupal-8.0.0-rc3.uk.po');
if (($handle = fopen("locales_location.csv", "r")) !== FALSE) {
while (($data = fgetcsv($handle, 1000, ";")) !== FALSE) {
if (!strpos($translation, $data[2])) {
print $data[2] . ' --- ' . $data[3] . "\n";
}
}
fclose($handle);
}This found several false positives. I did not want to futz with trying to do the same string breakup as in the .po file. So manually checked a few of each type of string (tour, email, etc). All seem to be in the localize copy EXCEPT:
l, F j, Y - H:i --- PHP date format
D, m/d/Y - H:i --- PHP date format
m/d/Y - H:i --- PHP date formatSo apparently we have some problem with translating the default date formats.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 2611658-12.patch | 2.39 KB | herom |
| #12 | 2611658-12.test-only.patch | 1.9 KB | herom |
| #12 | interdiff-2611658-10-12.txt | 947 bytes | herom |
| #11 | 2611658-10.patch | 2.39 KB | herom |
| #10 | 2611658-10-test-only.patch | 1.9 KB | herom |
Comments
Comment #2
gábor hojtsyComment #3
gábor hojtsyThese come from default long, medium and short dates. Note that their labels do appear in the .po output, eg. "Default long date".
Comment #4
gábor hojtsyThe files are core.date_format.[long|medium|short].yml BTW.
Comment #5
gábor hojtsyThat seems to be due to booleans not cast to proper ints for the type resolution (from core data types):
# Unlocked date formats should use the translatable type.
core_date_format_pattern.0:
type: date_format
label: 'Date format'
# Locked date formats are just used to transport the value.
core_date_format_pattern.1:
type: string
label: 'Date format'
Booleans should be cast to ints for dynamic type name resolution :)
Comment #6
gábor hojtsyTest (I think).
Comment #7
gábor hojtsyErm, based on what happens with core, that was not supposed to pass :/
Comment #8
herom commentedYeah, this was a boolean casting issue. Basically, this change #2533746: Remove the the ability to translate locked date formats (e.g. html_datetime) needed to happen in potx too. Tested this on core, and date formats are extracted too.
Comment #9
gábor hojtsyComment #10
herom commentedLet's try #6, but changing "_[...]" to ".[...]"
Comment #11
herom commentedoops.
Comment #12
herom commentedFigured it out. Potx failed when casting "false" booleans only.
Here's part of the result, after replacing the "core_date_format_pattern.[%parent.locked]" patterns in config (before the patch):
Comment #14
herom commentedYay, working test now.
Comment #16
gábor hojtsyYeah it totally makes sense, that bool cast to string would be "" and "1" right. Sorry for not providing the right test up front :D