I just went through an install of D7 and didn't expect 1 & 2 to be translated (how could they be), however 3-9 should be translated after I've selected my language and have the .po file in the right place:

1. Choose profile
2. Choose language
3. Verify requirements
4. Set up database
5. Install profile
6. Set up translations
7. Configure site
8. Finish translations
9. Finished

I had previously run into this issue here but wanted to bring this up to ensure it's fixed before it's released.
#513940: Installation task progress is not determinable non-visually

Comments

David_Rothstein’s picture

I saw this once too while testing out the installer but I attributed it to the fact that I was using a Drupal 6 translation for the test and figured that maybe the installer text changed so much between D6 and D7 that there were no strings that matched anymore? Probably not a good assumption to make - I'm sure something stayed the same :)

So it sounds like a bug. Is there a particular set of translation files available for D7 that is good to test this with?

mgifford’s picture

StatusFileSize
new59.72 KB

I've attached a French .po file from profiles/default/translations that has the above strings in it and should be expressed as:

1. Choix du profil

3. Vérification des pré-requis
4. Installation de la base de données
5. Installation du profil
6. Installation des traductions
7. Installation du site
8. Finalisation des traductions
9. Fin de l'installation

I'm not sure how one would be able to choose a profile in any other language other than English, so not sure the first translation is relevant:

#: install.php:950
msgid "Choose profile"
msgstr "Choix du profil"

#: install.php:952
msgid "Verify requirements"
msgstr "Vérification des pré-requis"

#: install.php:953
msgid "Set up database"
msgstr "Installation de la base de données"

#: install.php:954
msgid "Install profile"
msgstr "Installation du profil"

#: install.php:955
msgid "Set up translations"
msgstr "Installation des traductions"

#: install.php:967
msgid "Install site"
msgstr "Installation du site"

#: install.php:987
msgid "Finish translations"
msgstr "Finalisation des traductions"

#: install.php:992
msgid "Finished"
msgstr "Fin de l'installation"

I do get strings translated when I get into the site past the install though. Just tested it again on another space to confirm this wasn't a fluke in one install.

plach’s picture

Status: Active » Needs review
StatusFileSize
new652 bytes

Here is an attempt to solve the issue (see #678916: st() should take into account string contexts for details).

andypost’s picture

@plach I've tested installation with russian language without any patches and it works without exceptions and warnings.
My ru.po.

Going to try to pay attention on this issue coming from #678916: st() should take into account string contexts

mgifford’s picture

I've been trying to test patch #3. Ran into some trouble initially because the profile directory had changed and I was trying to just use a stock v6 translation file. Using @andypost's code however I received an install error:

* Notice: Undefined index: ru_22 in locale_add_language() (line 355 of drupal-cvs/includes/locale.inc).
* Notice: Undefined index: ru_22 in locale_add_language() (line 356 of drupal-cvs/includes/locale.inc).

SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'name' cannot be null

@plach's Italian translation provided a similar error.

Is there anything else which should be included in the profile/standard/translations file?

@andypost can you try it with the recent cvs to see if it is still working for you?

andypost’s picture

@mgifford last couple of days there's a lot of patches was commited, so I scare to suppose the state of this issue.

But to solve your problem - just rename a file to .po after you download it. So ru_22.po should be ru.po

mgifford’s picture

StatusFileSize
new197.38 KB

Right. Renaming the file resolved the errors.

I still don't get these translations:

msgid "Choose profile"
msgstr "Выберите профиль"
msgid "Verify requirements"
msgstr "Проверка требований"
msgid "Set up database"
msgstr "Установка базы данных"
msgid "Install profile"
msgstr "Профиль установки"
msgid "Set up translations"
msgstr "Установка переводов"
msgid "Install site"
msgstr "Установка сайта"
msgid "Finish translations"
msgstr "Завершение перевода"
msgid "Finished"
msgstr "Завершено"

When doing an install with the ru.po file. This is a diff of my code from core:

Index: includes/install.inc
===================================================================
RCS file: /cvs/drupal/drupal/includes/install.inc,v
retrieving revision 1.123
diff -r1.123 install.inc
953a954,955
>         // Select default context.
>         $locale_strings = $locale_strings[''];
mgifford’s picture

Issue tags: +i18n

Adding tag

mgifford’s picture

Status: Needs review » Reviewed & tested by the community
StatusFileSize
new114.97 KB

Not sure what (other than my system environment) changed, but I just set up this patch and it worked this time.

It was the first patch I applied off of a clean install, so perhaps there was some other conflict when I last tested this 2 weeks ago.

I also didn't see any warnings or errors with the install and the patch is very straight forward so I'm marking this as RTBC.

dries’s picture

The fact that we have to use the string '' to index the array is a bit odd. Can't we make this more elegant?

webchick’s picture

Status: Reviewed & tested by the community » Needs work
mgifford’s picture

Ok, I've spent a bit too much time looking at this today.

I've been trying to both verify the success I found on another machine (and reported above), and also figure out how the patch was intended to work.

The whole header redirection in the previous function install_goto() messes up a lot of basic debugging efforts. Was forcing in values with cookies to try to pull out what was and was not working.

It kept freezing for me after the string "Drupal can use CREATE TABLE database commands."

Not sure if somewhere within the DatabaseTasks something is messing up, but at this point it seems to be beyond my ability to resolve. For those who want to critique/improve or abandon my debugging approach within the st() function:

/**
 * Functional equivalent of t(), used when some systems are not available.
 *
 * Used during the install process, when database, theme, and localization
 * system is possibly not yet available.
 *
 * @see t()
 */
function st($string, $args = array()) {
  static $locale_strings = NULL;
  global $install_state;
  
  setcookie("TestState", serialize($install_state));
  
  if (!empty($locale_strings)) {
    setcookie("TestLocaleA", serialize($locale_strings));
  }
  
  // print_r($locale_strings);

  if (!isset($locale_strings)) {
    $locale_strings = array();
    if(!empty($locale_strings)) {    
      setcookie("TestLocaleD", serialize($locale_strings));
    }
    if(!empty($locale_strings)) {    
      setcookie("TestInside1", $string);
    } else {
      setcookie("TestInside2", $string);
    }
    
    if(!empty($locale_strings)) {    
      setcookie("TestArgs1", serialize($args));
    } else {
      setcookie("TestArgs2", serialize($args));
    }
    
    if(!empty($locale_strings)) {    
      setcookie("TestState1", serialize($install_state));
    } else {
      setcookie("TestState2", serialize($install_state));
    }
    if(!empty($install_state['parameters'])) {
      print_r($install_state['parameters']);
    }
    
    if ($string != 'Drupal can use CREATE TABLE database commands.') {
      print_r($locale_strings);
      print_r($install_state);
      echo "!! RED $string !!";
    } else {
      echo "beginning <pre>";
      print_r($locale_strings);
      print_r($install_state);
      echo "</pre>  !! BLUE $string !!";
    }
    
    if (isset($install_state['parameters']['profile']) && isset($install_state['parameters']['locale'])) {
      setcookie("TestParameters", serialize($install_state['parameters']));
      $filename = 'profiles/' . $install_state['parameters']['profile'] . '/translations/' . $install_state['parameters']['locale'] . '.po';
      setcookie("TestFilename", $filename);
      if (file_exists(DRUPAL_ROOT . '/' . $filename)) {
        require_once DRUPAL_ROOT . '/includes/locale.inc';
        $file = (object) array('uri' => $filename);
        setcookie("TestFile", serialize($file));
        _locale_import_read_po('mem-store', $file);
        $locale_strings = _locale_import_one_string('mem-report');
        setcookie("TestStringsA", $locale_strings);
        // Select default context.
        $locale_strings = $locale_strings[''];
        setcookie("TestStringsB", $locale_strings);
      }
    }
  }

  require_once DRUPAL_ROOT . '/includes/theme.inc';
  // Transform arguments before inserting them
  foreach ($args as $key => $value) {
    switch ($key[0]) {
      // Escaped only
      case '@':
        $args[$key] = check_plain($value);
        break;
      // Escaped and placeholder
      case '%':
      default:
        $args[$key] = '<em>' . check_plain($value) . '</em>';
        break;
      // Pass-through
      case '!':
    }
  }
  if (!empty($locale_strings[$string])) {
    setcookie("TestLocaleB", serialize($locale_strings[$string]));
  }
  
  if (!empty($string)) {
    setcookie("TestLocaleC", serialize($string));
  }
  if (!empty($string)) {
    setcookie("TestArg", serialize($args));
  }
  return strtr((!empty($locale_strings[$string]) ? $locale_strings[$string] : $string), $args);
}
sun.core’s picture

Status: Needs work » Needs review

#3: st-654726-3.patch queued for re-testing.

sun.core’s picture

If this patch fixes this issue, let's be done with it, please.

mgifford’s picture

It did in one instance

#11 It worked fine in my tests (in a new install)

#14 it didn't (although for the life of me I couldn't say why other than it was a different computer)

In trying to debug this I got lost. Code was not allowing me to access (either by echo or cookie) the values being set.

Someone else needs to look at this before it's considered fixed.

sun’s picture

The fact that we have to use the string '' to index the array is a bit odd. Can't we make this more elegant?

Too late to change APIs, I guess.

sun’s picture

#3: st-654726-3.patch queued for re-testing.

mgifford’s picture

I just tested this again. After selecting the Italian I wasn't able to get it to display in the installation. I was using the minimal profile with a profiles/minimal/translations/it.po file with related strings:

 885 #: install.php:954
 886 msgid "Install profile"
 887 msgstr "Profilo d'installazione"
 888 
 889 #: install.php:955
 890 msgid "Set up translations"
 891 msgstr "Imposta traduzioni"
 892 
 893 #: install.php:967
 894 msgid "Install site"
 895 msgstr "Installa il sito"
 896 
 897 #: install.php:987
 898 msgid "Finish translations"
 899 msgstr "Completa traduzioni"
 900 
 901 #: install.php:992
 902 msgid "Finished"
 903 msgstr "Finito"
 904 
 905 #: install.php:1009
 906 msgid "To configure your website, please provide the following information."
 907 msgstr "Per configurare il sito, inserisci le seguenti informazioni."
 908 
 909 #: install.php:1025
 910 msgid "Site e-mail address"
 911 msgstr "Indirizzo e-mail del sito"

Hopes this helps to clarify that this is still a problem (with or without the patch).

catch’s picture

Status: Needs review » Needs work

Looks like this still needs work.

bdurbin’s picture

Status: Needs work » Needs review
StatusFileSize
new784 bytes
new860 bytes

It appears that st() wasn't kept in sync with t() in terms of its arguments, so it doesn't support the third $options argument, which is how t() makes itself aware of the new message context (msgctxt) attribute of a translatable item. The more elegant solution would seem to be adding the $options argument to st(), so that consumers of that function can use message contexts. The first attached patch does this.

If adding a third optional argument to st() is considered an API change and it's too late for D7, we can just hard-code in the default context. The second patch below does this, and is really just a more readable version of the first patch submitted to this issue. While it doesn't require any API changes, this does keep consumers of st() from being able to use message contexts, or anything else that we've added to $options in t().

Here's what I did to test:

  • Patch using either of the two patches attached to this message
  • Download sample translation files from #3 above, and/or from http://drupal.org/node/678916
  • Run through installation, choosing a non-English language
  • Starting at installation step 3, the interface should start being translated into your selected language
andypost’s picture

I think we should keep t() and st() in-sync!
Also because install_drupal() calls drupal_language_initialize() ininstall_begin_request() all 1-9 strings should be translated

Te question is if we have more then 1 install profile which (lang).po file should be taken for translation?

sun’s picture

Status: Needs review » Needs work
Issue tags: +API change

They definitely need to be kept in sync.

+++ includes/install.inc.patched	2010-04-23 19:01:17.000000000 -0700
@@ -848,9 +848,13 @@ function install_goto($path) {
+  ¶
...
+  }  ¶

Trailing white-space here.

Any chance to add a test for this? Perhaps in a generic manner, so we'd hopefully catch future changes to t() that miss to update st()?

Powered by Dreditor.

andypost’s picture

I rephrase my question:

Step 1 - Choose profile, so we need to get .po files for languages when displaying this screen

What profile should be scanned for string translations? I think "default" but if "default" is not found...

Any ideas?

ChaosD’s picture

Status: Needs work » Needs review

sorry - retested out of couriosity

bdurbin’s picture

StatusFileSize
new965 bytes

Re-rolled patch after removing trailing white space. Choose to go with the patch that syncs st()'s signature with t()'s based on the feedback above.

As far as automagically choosing a locale and translating the text for steps 1-2, that might be nice but it seems outside of the scope of this issue, no?

sun’s picture

--- includes/install.inc	2010-04-23 19:10:48.000000000 -0700
+++ includes/install.inc.patched	2010-04-24 17:03:27.000000000 -0700

Can we roll a patch against CVS?

We also want to add tests.

Aside from that, I didn't understand the recent question/discussion about automatic locale selection. Could someone summarize that issue?

tobiasb’s picture

StatusFileSize
new31.13 KB
new27.57 KB
new981 bytes

patch via cvs and 2 pics which shows thats the patch works

catch’s picture

Status: Needs review » Reviewed & tested by the community

Patch looks good, can't test the installer, screenshots are nice. Automagic locale selection is a feature request for a completely different issue.

bdurbin’s picture

Status: Reviewed & tested by the community » Needs review
StatusFileSize
new705 bytes

Here's a test that ensures that the function signatures for t() and st() match. Could use some guidance on where in the test suite this should live. I see a blank "tests" folder in the includes folder, but I'm not sure how to properly incorporate the test outside of a testing module.

bdurbin’s picture

Status: Needs review » Reviewed & tested by the community

Unintentional status change on the last post.

sun’s picture

Status: Reviewed & tested by the community » Needs work

We should incorporate that test into common.test or locale.test. (wherever other tests for t() are currently living)

bdurbin’s picture

Status: Needs work » Needs review
StatusFileSize
new1.25 KB

Added the test to locale.test. Patch against CVS attached. Verified that with the current install.inc in CVS, the test fails. After patching install.inc using the patch in #29, the test passes.

To verify the test: run the "t() and st() signature checks" test from within the Locale group, both before and after patching your instance with the patch from #29.

sun’s picture

Status: Needs review » Needs work

Patch is missing the actual change.

catch’s picture

While we can't test the installer, we could write some tests for st() couldn't we? If we don't have any tests for it to build off though, this at least enforces that it's somehow kept in sync with t().

bdurbin’s picture

Status: Needs work » Needs review
StatusFileSize
new2.39 KB

Blerg, sorry about that. Combined patch attached.

sun’s picture

Status: Needs review » Needs work
+++ modules/locale/locale.test	26 Apr 2010 17:53:03 -0000
@@ -1969,3 +1969,28 @@ class LocalizeDateFormatsFunctionalTest 
+ *  Test for making sure the t() and st() functions have matching signatures

1) Duplicate leading space.

2) Missing trailing period.

3) This test case for st() should be enhanced in the future, so the summary should be more generic.

+++ modules/locale/locale.test	26 Apr 2010 17:53:03 -0000
@@ -1969,3 +1969,28 @@ class LocalizeDateFormatsFunctionalTest 
+      'name' => 't() and st() signature checks',
+      'description' => 'Tests that the number and types of arguments for t() and st() are the same.',

Same as above; name and description should be more generic.

+++ modules/locale/locale.test	26 Apr 2010 17:53:03 -0000
@@ -1969,3 +1969,28 @@ class LocalizeDateFormatsFunctionalTest 
+  function setUp() {
+    parent::setUp('locale');
+  }
...
+    $reflector_st = new ReflectionFunction('st');

st() is defined in install.inc, but install.inc is not loaded here. setUp() should load it.

Therefore, this reflection test is only valid, if this patch failed. Otherwise, the test passed without st() being actually defined.

+++ modules/locale/locale.test	26 Apr 2010 17:53:03 -0000
@@ -1969,3 +1969,28 @@ class LocalizeDateFormatsFunctionalTest 
+  function testStSignature() {

Missing docblock header (the current docblock of the class would be more suitable here).

+++ modules/locale/locale.test	26 Apr 2010 17:53:03 -0000
@@ -1969,3 +1969,28 @@ class LocalizeDateFormatsFunctionalTest 
+    $this->assert(($params_t == $params_st), t('The t() and st() function signatures must match.'));

1) Should use assertIdentical().

2) Assertion message should read like a confirmation, i.e. "Function signatures of t() and st() are identical."

96 critical left. Go review some!

sun’s picture

The last patch passed, but should have failed. So either the test code is wrong, or install.inc is magically loaded somewhere else, or the test code actually does not work.

sun’s picture

Status: Needs work » Needs review
StatusFileSize
new3.93 KB

Hm. DrupalWebTestCase::setUp() loads install.inc to perform the test environment installation. Nevertheless, we should ensure it's loaded.

So this one should be ready to fly.

Status: Needs review » Needs work

The last submitted patch, drupal.locale-st.40.patch, failed testing.

sun’s picture

Status: Needs work » Needs review
StatusFileSize
new3.92 KB

So they are equal, but not identical?

tstoeckler’s picture

StatusFileSize
new3.92 KB
+++ modules/locale/locale.test	27 Apr 2010 21:12:27 -0000
@@ -958,6 +958,35 @@ EOF;
+   * Verify that function signatures of t() and st() are identical.

Misleading comment in that case...

Rerolled for that change.

97 critical left. Go review some!

sun’s picture

Status: Needs review » Reviewed & tested by the community

Thanks!

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Agreed that the proper fix here is to keep t() and st() in sync.

Patch looks good, and even better with tests. :) Committed to HEAD. Thanks!

Status: Fixed » Closed (fixed)

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