Make English a first class language

Subscribe.

subscribe.

subscribe

its like a hook_alter %)
possibly we have to provide translation layers for this?
Language merging for different modules with different weight

If we provide multiple languages at site with different styles possibly we can provide some layers for them

example module commerce with UA translation for government and more freestyle UA translation
merging theese translations in different way per-module base would be nice... possibly...

Some suggestions that arose from discussions at the code sprint:

• Use "System language" as a label, instead of "Built-in interface text".
• On the Languages page, add a row for the System language (with no operations).

Patch no longer applied. Re-rolled it and changed system language label. I'm not convinced about adding the system language to the Languages page.

However it seems to breaks the tests — all the tests — when trying to run any test while Locale is enabled. I did not investigate this. Perhaps a similar issue to #276153: Testing does not work at all when locale of host session is not English.

I posted a mockup of the discussions we had at the Montreal coding sprint in #1260860: Rework language list admin user interface. There are a few other items on the page, but the system language as default is displayed as locked to the bottom and greyed out so users have a representation of what's going on.

I'm including it here for at least clarity's sake. So many issues are on this topic!

subscribing

I love this. Translating English to English :-)

Btw, there's some issue that arises with allowing customizing English strings: when you translate to another language the 'source' string displayed to the translator (if translating from English) needs to be the customized English string, not the source-hardcoded string.

* Which btw, will render our translations useless for contributing them back so we'll need to carefully handle this later. I.e. no option to push back to server translations of customized strings.

And then, why not being able to choose the source language for translating? Once you start customizing strings, the main 'source language' may not be English, but any other. The source language should be your primary site language, which is the one you are supposed to start customizing strings in, then they'll need translation to English.

"The above patch only failed 3 times", true, in the testbot. But applying this patch to to 8.x-dev and running the "Language configuration" test on my laptop throws an exception without even running.

An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: /batch?render=overlay&id=4&op=do StatusText: Service unavailable (with message) ResponseText: Additional uncaught exception thrown while handling exception.OriginalPDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'd8mi2.locales_source' doesn't exist: SELECT s.lid, t.translation, s.version FROM {locales_source} s LEFT JOIN {locales_target} t ON s.lid = t.lid AND t.language = :language WHERE s.source = :source AND s.context = :context; Array ( [:language] => en [:source] => @count passes [:context] => ) in locale() (line 666 of /Applications/MAMP/htdocs/d8mi/modules/locale/locale.module).AdditionalPDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'd8mi2.locales_source' doesn't exist: SELECT s.lid, t.translation, s.version FROM {locales_source} s LEFT JOIN {locales_target} t ON s.lid = t.lid AND t.language = :language WHERE s.source = :source AND s.context = :context; Array ( [:language] => en [:source] => %type: !message in %function (line %line of %file). [:context] => ) in locale() (line 666 of /Applications/MAMP/htdocs/d8mi/modules/locale/locale.module).

I therefore can't for now reproduce the errors from the testbot on my personal dev site. Investigating; David's comment in #9 seems relevant: something in Simpletest requires the system language to be "en" and everything breaks when system language is something else. However, why does a local test break and not the testbot? Looking into it.

Suscribing.

Great work on this issue, folks!

I think this general approach definitely makes sense, as long as it's transparent to English sites what's going on under the hood. Being able to provide "Better English" translations for Drupal using the same tools as you provide other translations makes a lot of sense, too. Thanks for the walk-through of this at the sprint, Gábor, and great job on the mockups, Erin!

To reproduce the testing errors from the testbot on my local dev site, I must change "built-in" back to "en" on line 1469 of includes/bootstrap.inc, after having applied the patch.

More on the tests:

The enclosed patch should only fail twice instead of three times.

- the reason why it is not possible to translate in the UI of a local is because the t() function throws an exception during the installation phase of certain tests, making it seem as if all tests are broken.
- in reality there seem to be only three broken tests in the patch on #9, above:
- the first is quite straightforward and has been addressed in the patch I am submitting now: instead of asserting that english can't be deleted, assert that english *can* be deleted (but to do that I had to add a new language first and make that the default) -- there's probably some cleaning up to do in that test.
- the other two I'm having a hard time getting my head around, but it has to do with t() being called at some point when the tables associated with the locale module have not yet been created.

Cheers,

Albert.

sub

subscribe

Please unlock the issue as #19 is still valuable for reviewers right?
I wanted to add comment #19 into the summary by http://drupal.org/node/1266318/edit

Nice work btw :-)

Strange and kinda scary as there are privileged d.o users for issue summary ... wtf ... I'm working on this tiny dreditor #1277974: Button to prepend the 'Issue summary standard' template into Issue body.

And yes we need to fix the patch too :-)

I applied #24 then on a fresh d8

drush --yes site-install
drush --yes en locale

PHP Fatal error:  Call to undefined function locale_language_save() in /Users/clemens/Sites/drupal/d8/www/modules/locale/locale.install on line 19
PHP Stack trace:
PHP   1. {main}() /Users/clemens/.drush/drush/drush.php:0
PHP   2. drush_main() /Users/clemens/.drush/drush/drush.php:41
PHP   3. drush_dispatch() /Users/clemens/.drush/drush/drush.php:101
PHP   4. call_user_func_array() /Users/clemens/.drush/drush/includes/command.inc:214
PHP   5. drush_command() /Users/clemens/.drush/drush/includes/command.inc:0
PHP   6. _drush_invoke_args() /Users/clemens/.drush/drush/includes/command.inc:806
PHP   7. call_user_func_array() /Users/clemens/.drush/drush/includes/command.inc:134
PHP   8. drush_pm_enable() /Users/clemens/.drush/drush/includes/command.inc:0
PHP   9. drush_module_enable() /Users/clemens/.drush/drush/commands/pm/pm.drush.inc:708
PHP  10. module_enable() /Users/clemens/.drush/drush/commands/core/drupal/environment.inc:103
PHP  11. module_invoke() /Users/clemens/Sites/drupal/d8/www/includes/module.inc:448
PHP  12. call_user_func_array() /Users/clemens/Sites/drupal/d8/www/includes/module.inc:795
PHP  13. locale_install() /Users/clemens/Sites/drupal/d8/www/includes/module.inc:0
Drush command terminated abnormally due to an unrecoverable error.                         [error]
Error: Call to undefined function locale_language_save() in /Users/clemens/Sites/drupal/d8/www/modules/locale/locale.install, line 19

On admin/config I get

Notice: Undefined index: en in locale_get_plural() (line 716 of /Users/clemens/Sites/drupal/d8/www/modules/locale/locale.module).
Notice: Trying to get property of non-object in locale_get_plural() (line 716 of /Users/clemens/Sites/drupal/d8/www/modules/locale/locale.module)

-- my 2 cents

+++ b/modules/locale/locale.pages.inc
@@ -191,7 +188,7 @@ function locale_translation_filters() {
-    'options' => array_merge(array('all' => t('All languages'), 'en' => t('English (provided by Drupal)')), $languages),
+    'options' => array_merge(array('all' => t('All languages'), LANGUAGE_SYSTEM => t('System (English)')), $languages),

"System (English)" feels weird. What about "Internal (English)"?

I agree "System (English)" is better then "English (System)"

+++ b/modules/locale/locale.test
@@ -170,11 +170,47 @@ class LocaleConfigurationTest extends DrupalWebTestCase {
-    $this->assertText(t('The English language cannot be deleted.'), t('Failed to delete English language.'));
+    ¶
+    $this->drupalPost('admin/config/regional/language/delete/en', array(), t('Delete'));

Whitespace

Subscribing. Patch looks lovely so far.

Hi all, while working on this I have installed a few d8 instances, and when I try to install Drupal in a language other than English (with or without this patch), I get

Call to undefined function _locale_import_read_po() in ../includes/install.inc on line 1113

That error seems unrelated to this patch: I have documented it here and submitted a patch to fix it, in case you come across the same problem:

http://drupal.org/node/1297506#comment-5066302

Cheers, and thanks to everyone for your work,

Albert.

Regarding the paths, it seems that with this patch, Dupal adds the 'en' prefix when it should not, in many circumstances. For example, on the 12th screenshot of LocalePathFunctionalTest (see sites/default/files/simpletest/verbose/LocalePathFunctionalTest-12.html once you run your test), we see

Existing system path *
http://localhost/english-d8/drupal8patched_FR/?q=en?q=

Notice ?q=en?q=, which is just plain ugly.
The LocalePathFunctionalTest fails also later on, the "First node links to the path alias." assertion. Given an alias "whatever" for node/1, the test expects the link to render as whatever for english, but it renders as en/whatever. Looking into this.

update on comment 39: after a few tries, I can't reproduce this when I'm actually using the site, only in the automated tests. To be continued.

Hi all,

Regarding paths, a few notes:

(1) scrap my comment at #40: when reproducing exactly what's in the test (including non-clean URLs), this can be reproduced.

(2) I have tracked down the function that adds the "en" prefix when it probably should not: it is locale_language_url_rewrite_url() in includes/locale.inc. Specifically, the lines

      case LOCALE_LANGUAGE_NEGOTIATION_URL_PREFIX:
        if (!empty($options['language']->prefix)) {
          $options['prefix'] = $options['language']->prefix . '/';
        }
        break;

.

It seems locale_language_url_rewrite_url() should not be adding a prefix if we are dealing with the default language.

@gabor thanks for the comment. I better understand it now. I'll be on a trip for the coming week, so I'll gladly look at this upon my return.

One thought though: if the prefix for english is '', then when another language than English is set to be the default, won't it be impossible to move back to English when language negociation is set to "path prefix"? In that sense, I'm not clear on whether it is actually a good idea to set the prefix of English to ''.

Cheers,

Albert.

@gabor thanks! I'm not (yet!) too well versed in the internationalization system so your explanation is appreciated. If you have a link to the discussions around this, please pass them on here.

I corrected a typo on your patch: you had langugae_default(), I put language_default() instead.

For those (such as myself) wondering why the testbot displays "PASSED" when there are "0 pass(es)": see http://drupal.org/node/873496

Cheers,

Albert.

...and here is your patch with the correction.

let's trigger the testbot

Hi all,

I did a few (manual) tests with the latest patch:

- I installed two 8.x (latest dev), one with the patch at 47, one with the patch at 61
- I installed both sites in French.

Trying to figure out where to set "locale_translate_english" in the UI.

Albert.

oops

Perhaps the "allow translation to English" should be in the language list page (seems more intuitive). Other than that, the patch at #61 works fine both for French and English installations.

Here's a modified version of the patch at 61 which adds some simpletest validation:

- makes sure we can't translate strings to english by default
- makes sure the string translation page has a field allowing the translation of a string to english once you checked "enable interface translation to english" on admin/config/regional/language/edit/en

This test makes sure it is possible to enter a value in English for a string on the site. Ideally we would also test that this actually works. (manual tests show it does: an automated test would be good).

Albert.

@Gábor yes, taking a look at that this morning.

Cheers,

Albert.

Is it possible to update the issue summary with a step through guide? I myself always get lost in all pages :(

Especially when to enable a second language? What install steps to check? I'll try to review later this week.

Hi all,

I have attempted to improve the testing here so that we can confirm that translating a string to English actually works.

- I can confirm after manual testing that translating a string from the system language to English works.
- I have added a test which revisits the string translation page after having put in a translation for English, and confirming that the translation is still present.
- However, calling t($string, array(), array('langcode' => 'en')), as suggested by Gábor in comment 66, does not seem to work during testing; it returns the original string and not the translated string.

I am including two patches here:

- patch (A) should pass all tests -- it differs from the patch in 65 in that it revisits the string translation page, confirming that the translation to English is persistent, among other (trivial) tests.
- patch (B) fails once -- the following line fails:

$this->assertTrue($name != $translation_to_en && t($name, array(), array('langcode' => 'en')) == $translation_to_en, t('t() works for English.'));

Within the context of the test, the static locale_t within the locale() function does not contain the correct information, making the above code return the original string for 'en' even if a translation exists. To make the test (B) pass,
- apply the patch
- In locale.module's locale() function, after $locale_t = &drupal_static(__FUNCTION__);, add $locale_t['en'] = NULL;
- run the tests.
I'm not quite sure what to make of this, so your thoughts are welcome!

Albert.

Setting to needs work until we can explain why the patch at 71-b fails once. Feel free to set back to needs review if that is the standard when the functionality needs review but the test needs work.

Albert.

@Gábor thanks! I was scratching my head over that. So here's an updated patch which passes all tests.

#74: make-english-first-class-1266318-74.patch queued for re-testing.

Committed/pushed to 8.x, thanks!

I somehow expected the issue summary 'Remaining Tasks' be empty.

As http://drupal.org/node/1323140 will direct users back to this issue it would be great to have a finished issue summary right?

Use more permissive format now that local images are allowed.