Closed (fixed)
Project:
Drupal core
Version:
7.x-dev
Component:
install system
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
8 Dec 2009 at 21:09 UTC
Updated:
14 May 2010 at 16:22 UTC
Jump to comment: Most recent file
Comments
Comment #1
David_Rothstein commentedI 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?
Comment #2
mgiffordI'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.
Comment #3
plachHere is an attempt to solve the issue (see #678916: st() should take into account string contexts for details).
Comment #4
andypost@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
Comment #6
mgiffordI'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?
Comment #7
andypost@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
Comment #8
mgiffordRight. 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:
Comment #9
mgiffordAdding tag
Comment #11
mgiffordNot 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.
Comment #12
dries commentedThe fact that we have to use the string '' to index the array is a bit odd. Can't we make this more elegant?
Comment #13
webchickComment #14
mgiffordOk, 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:
Comment #15
sun.core commented#3: st-654726-3.patch queued for re-testing.
Comment #16
sun.core commentedIf this patch fixes this issue, let's be done with it, please.
Comment #17
mgiffordIt 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.
Comment #18
sunToo late to change APIs, I guess.
Comment #19
sun#3: st-654726-3.patch queued for re-testing.
Comment #20
mgiffordI 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:
Hopes this helps to clarify that this is still a problem (with or without the patch).
Comment #21
catchLooks like this still needs work.
Comment #22
bdurbin commentedIt 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:
Comment #23
andypostI 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?
Comment #24
sunThey definitely need to be kept in sync.
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.
Comment #25
andypostI 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?
Comment #26
ChaosD commentedsorry - retested out of couriosity
Comment #27
bdurbin commentedRe-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?
Comment #28
sunCan 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?
Comment #29
tobiasbpatch via cvs and 2 pics which shows thats the patch works
Comment #30
catchPatch looks good, can't test the installer, screenshots are nice. Automagic locale selection is a feature request for a completely different issue.
Comment #31
bdurbin commentedHere'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.
Comment #32
bdurbin commentedUnintentional status change on the last post.
Comment #33
sunWe should incorporate that test into common.test or locale.test. (wherever other tests for t() are currently living)
Comment #34
bdurbin commentedAdded 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.
Comment #35
sunPatch is missing the actual change.
Comment #36
catchWhile 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().
Comment #37
bdurbin commentedBlerg, sorry about that. Combined patch attached.
Comment #38
sun1) 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.
Same as above; name and description should be more generic.
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.
Missing docblock header (the current docblock of the class would be more suitable here).
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!
Comment #39
sunThe 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.
Comment #40
sunHm. 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.
Comment #42
sunSo they are equal, but not identical?
Comment #43
tstoecklerMisleading comment in that case...
Rerolled for that change.
97 critical left. Go review some!
Comment #44
sunThanks!
Comment #45
webchickAgreed 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!