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 format

So apparently we have some problem with translating the default date formats.

Comments

Gábor Hojtsy created an issue. See original summary.

gábor hojtsy’s picture

StatusFileSize
new31.46 KB
gábor hojtsy’s picture

These come from default long, medium and short dates. Note that their labels do appear in the .po output, eg. "Default long date".

gábor hojtsy’s picture

The files are core.date_format.[long|medium|short].yml BTW.

gábor hojtsy’s picture

That 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 :)

gábor hojtsy’s picture

Status: Active » Needs review
StatusFileSize
new1.9 KB

Test (I think).

gábor hojtsy’s picture

Erm, based on what happens with core, that was not supposed to pass :/

herom’s picture

StatusFileSize
new495 bytes

Yeah, 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.

gábor hojtsy’s picture

Issue tags: +Needs tests
herom’s picture

StatusFileSize
new1.9 KB
new495 bytes

Let's try #6, but changing "_[...]" to ".[...]"

herom’s picture

StatusFileSize
new2.39 KB

oops.

herom’s picture

StatusFileSize
new947 bytes
new1.9 KB
new2.39 KB
new2.39 KB

Figured 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):

core_date_format_pattern.1
core_date_format_pattern.1
core_date_format_pattern.1
core_date_format_pattern.
core_date_format_pattern.
core_date_format_pattern.

The last submitted patch, 12: 2611658-12.test-only.patch, failed testing.

herom’s picture

Issue tags: -Needs tests

Yay, working test now.

  • Gábor Hojtsy committed c5a88ab on 7.x-3.x
    Issue #2611658 by herom, Gábor Hojtsy: PHP date format strings are not...
gábor hojtsy’s picture

Status: Needs review » Fixed

Yeah it totally makes sense, that bool cast to string would be "" and "1" right. Sorry for not providing the right test up front :D

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.