Problem/Motivation

As part of the l10n_update integration in core this issue adds the function to Download and import interface translations. See the UML in #1191488: META: Integrate l10n_update functionality in core for the big picture where this fits in.

Proposed resolution

The installation process is being discussed. Latest proposed workflow is found in #26

Remaining tasks

  • Make language selection work according to agreed workflow.
  • Make the import working in both interactive and non-interactive mode.
  • Add cron-implementation (separate issue)
  • Background information on use of the Drupal Translation server. (link on the first page)

User interface changes

  • The first step of the installation ('Choose language')
  • Fault messages when a translation can not be downloaded

API changes

None.

How to test the patch

  1. Check-out the latest Drupal 8.x-dev.
  2. Apply the latest patch from this queue.
  3. To test without pre-installed po files: make sure your sites/*/files/translations directory is empty
  4. Start the installation: example.com (or example.com/install.php)
  5. Choose English or a non-English language (go wild here ;) )
  6. The following installer steps will be displayed in your selected language.

Note that if you went too wild, the installer pages will only be partially (or minimally) translated.
Before downloading a translation, a few checks are made. To test these you can introduce the following bugs: Remove write permission of the translations directory (sites/*/files/translations) of turn off your internet connection.

CommentFileSizeAuthor
#80 Requirements problem | Drupal.jpg30.7 KBsteinmb
#67 weird-progress-bar.png14.15 KBwebchick
#64 Screen Shot 2013-01-08 at 11.38.42 PM.png57.06 KBwebchick
#64 Screen Shot 2013-01-08 at 11.49.15 PM.png149.42 KBwebchick
#64 full-error.txt322.93 KBwebchick
#45 locale-install-import-1848490-45.patch33.97 KBSutharsan
#45 interdiff-1848490-41-45.txt11.61 KBSutharsan
#42 lif-s01-create_translations_dir-2012-12-18_1833.png72.07 KBYesCT
#42 dif-s03-always_writable_true-2012-12-18_2142.png127.6 KBYesCT
#42 lif-s04-translates_right_away-2012-12-18_2230.png64.26 KBYesCT
#42 lif-s05-local_po-2012-12-18_2259.png32.42 KBYesCT
#42 locale-install-import-1848490-43.patch34.22 KBYesCT
#42 interdiff-39-41.txt4.36 KBYesCT
#41 locale-install-import-1848490-41.patch33.1 KBYesCT
#39 locale-install-import-1848490-39.patch33.95 KBSutharsan
#39 interdiff-1848490-38-39.txt23.51 KBSutharsan
#38 locale-install-import-1848490-38.patch28.72 KBSutharsan
#38 interdiff-1848490-2-38.txt26.87 KBSutharsan
#37 locale-install-import-1848490-37-do-not-test.patch28.38 KBSutharsan
#26 locale-1848490-flow-diagram-26.png135.97 KBSutharsan
#26 locale-1848490-language-selection-26A.png193.28 KBSutharsan
#26 locale-1848490-language-selection-26B.png104.7 KBSutharsan
#6 icons-language-2012-11-24_2359.png71.47 KBYesCT
#6 icons-spanish-fewer-2012-11-25_0000.png77.86 KBYesCT
#5 locale-install-s01-ui-install-2012-11-24_2310.png47.9 KBYesCT
#5 locale-install-s02-dropdown-2012-11-24_2311.png81.79 KBYesCT
#5 locale-install-s03-2012-11-24_2312.png67.34 KBYesCT
#5 locale-install-s04-requirements-ok-2012-11-24_2316.png135.95 KBYesCT
#5 locale-install-s05-db-english-2012-11-24_2320.png97.2 KBYesCT
#5 locale-install-s07-translations-po-2012-11-24_2322.png70.15 KBYesCT
#5 locale-install-s06-install-english-2012-11-24_2321.png59.79 KBYesCT
#5 locale-install-s08-config-english-error-2012-11-24_2323.png135.1 KBYesCT
#5 locale-install-s08-config-spanish-witherror-Configure site | Drupal 2012-11-24 23-32-31.png161.42 KBYesCT
#5 locale-install-s09-spanish-not-noticable-2012-11-24_2334.png68.38 KBYesCT
#5 locale-install-s10-visit-site-2012-11-24_2336.png118.8 KBYesCT
#5 locale-install-s11-config-2012-11-24_2337.png84.73 KBYesCT
#5 locale-install-s12-no-english-2012-11-24_2339.png110.71 KBYesCT
#5 locale-install-s13-could-add-english-2012-11-24_2340.png107.9 KBYesCT
#5 locale-install-s14-detection-2012-11-24_2342.png165.78 KBYesCT
#5 locale-install-s15-extend-2012-11-24_2344.png106.79 KBYesCT
#4 d8-s01-install-language-text-2012-11-25_0045.png53.79 KBYesCT
#4 d8-s02-install-lang-helppage-2012-11-25_0046.png87.03 KBYesCT
#2 locale-install-import-1848490-2-for-testbot.patch205.41 KBSutharsan
#2 locale-install-import-1848490-2-for-review-do-not-test.patch21.19 KBSutharsan
#1 locale-install-import-1848490-1.patch17.63 KBSutharsan
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Sutharsan’s picture

Status: Active » Needs work
FileSize
17.63 KB

A first, and still dirty, patch which introduces the automatic translation import to the installer. The patch depends on #1804688: Download and import interface translations.

Sutharsan’s picture

Issue summary: View changes

Summary updated with 'todo'

Sutharsan’s picture

A fully working patch that adds automatic translation import when the localization server translations are online available. Falls back to file import if not.

The patch re-introduces the locale_translate_batch_import_files() function which got dropped in #1804688: Download and import interface translations. Although that code did not land yet, I don't want to stir up that patch by bringing the code back in.

Two patches added. One for review and one for the testbot which also includes the latest patch from #1804688: Download and import interface translations.

YesCT’s picture

Title: Make installation proces use automatically translation import » Make installation process use automatically translation import

I'm testing this now. I'll post results in a bit.

YesCT’s picture

YesCT’s picture

Overview

This is great!

Details

with the patch. ... since this depends on another patch, I'm including how I set up the testing in case used the wrong order, or wrong patch...

clean d8
735 git status
736 git checkout 8.x
737 sudo rm -r sites
738 git checkout site*
739 git pull --rebase
740 git reset --hard
741 git log
get the patch that would be committed
742 curl -O http://drupal.org/files/locale-install-import-1848490-2-for-review-do-no...
depends on 1804688-60
743 curl -O http://drupal.org/files/locale-download-import-1804688-60.patch
744 git checkout -b locale-download-import-1804688-60
745 git apply --index locale-download-import-1804688-60.patch
746 git status
747 git commit -m "60"
748 git status
749 git checkout -b locale-install-import-1848490-2-for-review-do-not-test
750 git apply --index locale-install-import-1848490-2-for-review-do-not-test.patch
751 git status
752 git commit -m "2"
756 drush -y sql-drop --db-url="mysql://root:root@localhost/d8-git"

test it.

01 site install page, note the instructions link for how to install in other languages is gone

locale-install-s01-ui-install-2012-11-24_2310.png

02 drop down has the languages. very nice.

locale-install-s02-dropdown-2012-11-24_2311.png

03 choose profile (is in english, note the langcode in the url)

cannot immediately switch to another language, because can't load the po file yet. ok.
locale-install-s03-2012-11-24_2312.png

04 requirements (still in english)

locale-install-s04-requirements-ok-2012-11-24_2316.png

05 set up database (still in english)

locale-install-s05-db-english-2012-11-24_2320.png

06 installation profile, modules installing (still in english)

locale-install-s06-install-english-2012-11-24_2321.png

07 new in the list of steps: set up translations (in english still)

locale-install-s07-translations-po-2012-11-24_2322.png

08 configure site (in spanish!)

at first I thought this was still in english, but when I looked at the error closer...
locale-install-s08-config-english-error-2012-11-24_2323.png

<div id="console"><div class="messages error">
<h2 class="element-invisible">Mensaje de error</h2>
The specified file <em class="placeholder">temporary://drupal-7.0.es.po</em> could not be copied because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.</div>
<div class="messages status">
<h2 class="element-invisible">Mensaje de estado</h2>
One translation file imported. <em class="placeholder">4427</em> translations were added, <em class="placeholder">0</em> translations were updated and <em class="placeholder">0</em> translations were removed.</div>
<div class="messages warning">
<h2 class="element-invisible">Mensaje de advertencia</h2>
3 translation strings were skipped because of disallowed or malformed HTML. <a href="/d8-git/admin/reports/dblog">See the log</a> for details.</div>
</div>

Mensaje de error

The specified file temporary://drupal-7.0.es.po could not be copied because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.

Mensaje de estado

One translation file imported. 4427 translations were added, 0 translations were updated and 0 translations were removed.

Mensaje de advertencia

3 translation strings were skipped because of disallowed or malformed HTML. See the log for details.

I saw it's in spanish! cool.

About error: also seen in #1804688-67: Download and import interface translations screenshot s06b.

08b

locale-install-s08-config-spanish-witherror-Configure site | Drupal 2012-11-24 23-32-31.png

09 Finished screen

locale-install-s09-spanish-not-noticable-2012-11-24_2334.png

10 Visit Site

It's in spanish! and no langcode in the url. nice.
locale-install-s10-visit-site-2012-11-24_2336.png

11 more nice things: configuration admin page shows languages and ui translation (locale) already enabled

locale-install-s11-config-2012-11-24_2337.png

12 more nice things: there is no english language

locale-install-s12-no-english-2012-11-24_2339.png

13 more nice things: I could add english

locale-install-s13-could-add-english-2012-11-24_2340.png

14 more nice things: detection and selection working as expected

locale-install-s14-detection-2012-11-24_2342.png

15 more nice things: can verify locale and language modules were enabled for me

locale-install-s15-extend-2012-11-24_2344.png

I checked it also with just the testbot patch and it behaved the same:

762 git status
763 git checkout 8.x
764 curl -O http://drupal.org/files/locale-install-import-1848490-2-for-testbot.patch
768 git checkout -b locale-install-import-1848490-2-for-testbot
769 git apply --index locale-install-import-1848490-2-for-testbot.patch
770 drush -y sql-drop --db-url="mysql://root:root@localhost/d8-git"
771 sudo rm -r sites
772 git checkout sites*
773 git status
774 git commit -m "2 testbot"

Summary

This is great.

Next Steps

1. Code review

2. The error could be a follow-up.

3. Expectations

I kind of expected to see english go away after I picked which language I wanted, but I understand why it cannot show up immediately.
Perhaps it would help to add the new items (Set up translations, Finish translations) into the list of steps earlier.. like after selecting a non english language for install. That would communicate when the language will switch during the install and help people have the right expectation which will reduce frustration and them reporting what they think is an error of their language not switching right away.

That could be a follow-up too. But if this gets re-rolled for something, like the error, or something else, then please add this in.

YesCT’s picture

The icons in the new toolbar are not shown (except for Extend) in another language (... just checked spanish).

Is this an unrelated follow-up?

English:
icons-language-2012-11-24_2359.png

Spanish:
icons-spanish-fewer-2012-11-25_0000.png

Gábor Hojtsy’s picture

@YesCT: the toolbar bug is at #1848552: Toolbar icons disappear with translated menu, it is unrelated to this patch.

As for the installer, I think the expected behaviour is that the installer is Spanish from the get-go (profile selection screen), and not only from the configure screen. That is why we moved the installer language selection to the first step :)

YesCT’s picture

Status: Needs review » Needs work

Needs work, to make all the screens after language selection in that language.

That would be starting with step 3 in #5.

Sutharsan’s picture

Status: Needs work » Needs review

@yesCT, thanks for your extensive review.
I agree that with the expectation that screens should be in the selected language as soon as possible after the the language has been selected. But that is not what this issue is about. This issue is about automating the translation import. I suggest to make a new issue about making all the screens after language selection in the selected language and don't try to combine it into this one.
The error message is the same as occurred during your tests of #1804688: Download and import interface translations, and I think the solution can be the same.

Gábor Hojtsy’s picture

[08:41am] GaborHojtsy: Sutharsan: looking at http://drupal.org/node/1848490
[08:41am] Druplicon: http://drupal.org/node/1848490 => Make installation process use automatically translation import => Drupal core, locale.module, normal, needs review, 9 comments, 4 IRC mentions
[08:42am] GaborHojtsy: Sutharsan: befre the patch if you had a language file in the common central directory, it would be used from right after the language selection
[08:42am] GaborHojtsy: Sutharsan: my assumption is the patch shows you download instructions right after language selection if no internet connection
[08:42am] GaborHojtsy: Sutharsan: otherwise it would download the file to this central dir
[08:42am] GaborHojtsy: Sutharsan: if that happens, the installer should *automatically* pick up the file without further effort from the patch
[08:43am] Sutharsan: GaborHojtsy: I have to look into that. Thanks for noticing
[08:44am] Sutharsan left the chat room. (Read error: Connection reset by peer)
[08:46am] GaborHojtsy: Druplicon: tell Sutharsan about http://api.drupal.org/api/drupal/core%21includes%21install.core.inc/function/install_find_translation_files/8
[08:46am] Druplicon: GaborHojtsy: I'll pass that on when Sutharsan is around.
Gábor Hojtsy’s picture

Status: Needs review » Needs work

Looking at the patch, what seems to be happening is that the localization server (ftp.drupal.org) gets a HEAD request when Drupal is attempted to be installed in a foreign language. If we get a 200, we move on with the assumption it is going to work, otherwise (if there were no local files), we display download instructions. The actual automated download happens later in the locale import step.

However, what the installer itself does is that it uses the core .po file for the installation process even before the locale import step is reached, if there is such a file there. So if we'd attempt do actually download the file right after the language was selected, (a) we'd get better information then just the download server merely being online (b) actually use the file for the installer from the start.

Looks like the download is integrated in a batch process with the import and such a batch process does not seem to be viable to run before any database is available? The good news is we only need to download one specific .po file (although if we want to do version fallback logic, we might need to do multiple HTTP requests). The import process can/should happen later. The mere presence of the file in the central directory will make the installer use it. That is what happens via http://api.drupal.org/api/drupal/core%21includes%21install.core.inc/func...

(BTW I believe this is an integration issue of existing features (once the download patch is committed), so this is not bound to the Dec 1st freeze).

Jose Reyero’s picture

The more I think of this it is more clear to me that the 'solution' is to just include the big drupal-8.x.lang.po file for each language within the Drupal installer, for a number of reasons:

- Adding http connections in the first stages of the installer introduces another problematic point of failure.
- This feature can be also considered 'calling home' without asking the user for confirmation, which is at the very least extremely unpolite (and also may be very unpopular, I think we've seen issues with that on other applications like Wordpress)
- We need a fallback in case the server, the connection, etc.. is not working so we should include the po files anyway.

Really, just packing some po files, now Drupal core codebase is becoming huge anyway, shouldn't be a major issue.

Then, once the first installation is done, we can just add a checkbox (similar to the 'update' one) that would trigger a translation update in the next steps.

Gábor Hojtsy’s picture

[7:45pm] Sutharsan: GaborHojtsy: I can work on http://drupal.org/node/1848490 tomorrow, but like to see your response on reyero's comment. I don't want to spent time on opposite solutions.
[7:45pm] Druplicon: http://drupal.org/node/1848490 => Make installation process use automatically translation import => Drupal core, locale.module, normal, needs work, 12 comments, 12 IRC mentions
[7:45pm] GaborHojtsy: Sutharsan: ha!
[7:47pm] GaborHojtsy: Sutharsan: yeah, I'm not sure including .po files for each language in core is viable, eg. the Hungarian translation is 680K for core: http://localize.drupal.org/translate/languages/hu
[7:47pm] GaborHojtsy: Sutharsan: it compresses down to about 210k with zip
[7:47pm] GaborHojtsy: Sutharsan: now we have views in core, which is another 157k uncompressed and many many more things
[7:48pm] GaborHojtsy: Sutharsan: we even on a low conservative estimate we are looking at 300k compressed for each language
[7:48pm] GaborHojtsy: Sutharsan: that is well translated
[7:48pm] Sutharsan: GaborHojtsy: is a reduced po file for only the installer an option?
[7:48pm] GaborHojtsy: Sutharsan: well, its a phone home later then
[7:48pm] GaborHojtsy: Sutharsan: so the argument does not hold for including something in the first place
[7:49pm] reyero: Sutharsan: GaborHojtsy: hi, I'm here
[7:49pm] GaborHojtsy: Sutharsan: also reyero is working to make installer code be able to use the same APIs, so we will not have info on which strings are installer only
[7:49pm] GaborHojtsy: Sutharsan: so we'll have this 800-900k big .po file to download (fun stuff)
[7:49pm] Sutharsan: GaborHojtsy: that is huge, indeed
[7:50pm] GaborHojtsy: Sutharsan: back to overall file sizes, so if we have like 10 good translations, that is 3Mb compressed and the whole of Drupal 7 is 3MB
[7:51pm] reyero: GaborHojtsy: how big is current Drupal core? because we should measure that in how much % it adds to core download
[7:51pm] GaborHojtsy: Sutharsan: so the compressed .po translations for core in 100 languages would outsize the whole core itself multiple times
[7:51pm] GaborHojtsy: reyero: current D7 translation is about 200k compressed (vs. 3MB compressed core download)
[7:52pm] reyero: Sutharsan: Drupal 7 was 3 Mb but I'm afraid D8 is getting way bigger
[7:52pm] GaborHojtsy: reyero: so about 15 complete translations compressed are the size of core compressed
[7:53pm] reyero: checking, current D8 (targ.gz) is 4.72 Mb
[7:54pm] reyero: surprisingly small 
[7:54pm] reyero: https://drupal.org/node/3060/release?api_version[]=7234
[7:54pm] Druplicon: https://drupal.org/node/3060 => Drupal core => 0 comments, 2 IRC mentions
[7:54pm] Sutharsan: GaborHojtsy: reyero: sorry, have to run now. No more time for discussion 
[7:54pm] GaborHojtsy: Sutharsan: I'll post this on the issue 
[7:55pm] Sutharsan: GaborHojtsy: thanks. Will read it tonight.
[7:55pm] Sutharsan left the chat room. (Quit: Sutharsan)
[7:55pm] GaborHojtsy: reyero: and the D7 views translation is 25% of the size of the core translation
[7:56pm] reyero: GaborHojtsy: Yeah, ok, that looks way too big
[7:56pm] GaborHojtsy: reyero: yeah
Gábor Hojtsy’s picture

[8:00pm] reyero: GaborHojtsy: The thing is I wouldn't be very happy with any of the options because, can you imagine some message like: "Nope you cannot install Drupal Hungarian today, the server is down" ?
[8:00pm] GaborHojtsy: reyero: well, currently (D7/D8) it tells you to figure out how to download a file manually
[8:00pm] GaborHojtsy: reyero: so if server is down, the same thing happens today
[8:01pm] GaborHojtsy: reyero: with the download after the language selection, we can give users a specific download link for the file if the server is down
[8:01pm] GaborHojtsy: reyero: which is already way user friendlier 
[8:01pm] GaborHojtsy: reyero: I know this concern of phone home is not resolved, but honestly not sure hot resolve it besides packaging Drupal core per language 
[8:02pm] GaborHojtsy: (which is what many desktop tools do like Firefox)
Gábor Hojtsy’s picture

TL;DR: probably needs more discussion, don't delve into implementation yet :)

[8:11pm] reyero: GaborHojtsy: back (sorry, got a phone call)
[8:11pm] reyero: GaborHojtsy: so, whatever we do I think just going for download without warning / options is not the right thing
[8:12pm] reyero: GaborHojtsy: if we eventually fix the default config issue, really you can download the translation anytime
[8:13pm] GaborHojtsy: reyero: yeah, but we want the installer to be in the language of the user, which was a key goal when we battled to move language to the first step 
[8:13pm] reyero: GaborHojtsy: so maybe what we need is still the installer translation packaged (all languages) and then the other part...
[8:13pm] GaborHojtsy: reyero: but it is already there in D7 that early so the rest of the installer is in your language
[8:14pm] GaborHojtsy: reyero: except we don't really know the installer strings, right?
[8:14pm] reyero: GaborHojtsy: right, we'll we know atm, but we were going to fix it 
[8:17pm] reyero: GaborHojtsy: so... everybody else in the world has different software downloads per language, I think.. (?)
[8:18pm] GaborHojtsy: reyero: well, big software like an operating system bundles it 
[8:18pm] reyero: GaborHojtsy: The point is now language selection is the first step, it doesn't even make sense to print the "Nope we cannot download your translation" untranslated
[8:19pm] GaborHojtsy: reyero: but otherwise, eg. http://www.mozilla.org/en-US/firefox/all.html
[8:20pm] reyero: GaborHojtsy: really, the big progress we can make (we are making) is being able to download the translation after the install without all that default strings being already in the db
[8:20pm] reyero: GaborHojtsy: I mean with config translation, it doesn't matter whether you download the translation before or after
[8:21pm] GaborHojtsy: reyero: yeah, well, the idea was that we loose the identification possibility, so we *need* to download ahead
[8:21pm] GaborHojtsy: reyero: l10n_drupal already includes installer translations 
[8:21pm] reyero: GaborHojtsy: So "ok, you cannot download it how, but you  can install your Spanish site, download the translation when available"
[8:21pm] GaborHojtsy: reyero: we can maybe somehow integrate that with the packaging on d.o (although will not be a one hour job 
[8:21pm] GaborHojtsy: reyero: I don't think we should commit .po files in git in the core repo
[8:22pm] reyero: GaborHojtsy: yes, we shouldn't, also when downloading modules, same issue, etc..
[8:23pm] GaborHojtsy: reyero: so how would we identify the installer strings then, we are just getting rid of that (for good IMHO 
[8:23pm] reyero: GaborHojtsy: I'm thinking now of other ways of identifying installer strings
[8:23pm] reyero: GaborHojtsy: if we just get the ones for some files/modules...
[8:24pm] reyero: GaborHojtsy: that wouldn't be exactly installer strings but a few more, that may be a manageable download size
[8:25pm] reyero: GaborHojtsy: say you get all strings under include, lib, and a few modules (system, locale...)
[8:26pm] reyero: GaborHojtsy: .which... um.. we have the same issues for distributions that may have different required modules...
[8:28pm] GaborHojtsy: reyero: right
[8:28pm] GaborHojtsy: reyero: so if we want to solve the opt-in problem
[8:29pm] GaborHojtsy: reyero: then we want to avoid phone-home up until AFTER the config screen
[8:29pm] GaborHojtsy: reyero: which can be heavily adapted by distros, such as drupal commerce
[8:31pm] reyero: GaborHojtsy: think about the steps, maybe an intermediate one like 'That translation is not here yet... you can download it manually and place it here (click).... or get it downloaded from the server (click)
[8:32pm] reyero: GaborHojtsy: that is a quite explicit 'ok, I want to connect to the server'
[8:32pm] reyero: GaborHojtsy: while it may also allow uploading files to the translation folder and we fix another issue
[8:33pm] reyero: GaborHojtsy: anyway... we need to think more about this
[8:33pm] reyero: GaborHojtsy: I need to go for a while, but I'll be back in 30'
[8:33pm] GaborHojtsy: reyero: ok
Sutharsan’s picture

@gaborhojtsy, @reyero, any update on your discussion? This issue is next on my list.

Gábor Hojtsy’s picture

@Sutharsan: I don't personally know of any progress. I think we agreed that language-specific downloads of Drupal 8 would not be good (packaging translation with core). We also want to remove st() and get_t() and $t() and have a patch which almost gets us there at #1813762: Introduce unified interfaces, use dependency injection for interface translation, so we will not have tools to identify installer strings. Jose suggested some alternative solutions above, like taking strings from some files only, but that does not really work for distributions.

My latest idea (just come up while writing this :) is that when you select a foreign language or have a foreign language selected for you based on browser preference, a checkbox should "magically" show up under the select field checked saying "I understand this downloads a file from {localization server url} to translate my site" or something so we have a clear indication that this calls out of Drupal to perform the operation and might be considered phone-home by some. Then move the .po download that early. This is just a sudden idea I just had, so might not be worth it to run and code it right away :)

Jose Reyero’s picture

I've been thinking a bit more about this and have some ideas too, it could go like this:

0. Select language.
1.1 If there's a po for that language -> go ahead w/ import and install
1.2 If no po file for that language, page with two options:
A. [Button] Download from the translation server
B. [Upload a translation file] Regular file upload control.
(C). Proceed with installation, download translation later.

This would have some important advantages:
- Explicit "Download", user needs to click on it.
- No more scary instructions like "download translation, move it to this server's file, etc..."

Gábor Hojtsy’s picture

Issue tags: +Usability

@Jose: looks like the interaction you proposed is a little more interaction-involved version of what I had in mind. So I guess the question is which one we prefer and consider a good solution to inform the user of the alleged phone-home happening (which I don't think is a practically occurring problem but I can see it would be alleged to happen). Tagging for usability and will try to ask for feedback.

Bojhan’s picture

Category: task » bug

Changing priority, this is not really a task - as it creates a usability bug currently in the installer you have a select list only to select one option. I already pointed to the fact earlier, that this is a significant decrease in usability - I would almost make it major.

I am not really fan of the proposed flow by Jose, it makes it significantly more troublesome than it needs to be - pretty much removing the whole "nice workflow" idea why we introduced this in the first place. I would seriously reconsider the idea you propose, because to me it completely defeats the purpose of the original idea. We can just have a text (not checkbox) appear when you select a different language (not in your install), that it will be downloaded from the translation server + a link for more info?

Gábor Hojtsy’s picture

I agree we want to make this as easy as possible, while making it as localized as possible :)

After further discussion with @Bojhan, just to make it clear @Bojhan's proposal is that the opt-out is that you install in English and then deal with the rest. The "link to the explanation" leads to text describing what happens if you install in a foreign language and that the English is your opt-out.

Gábor Hojtsy’s picture

Oh, and I do like that suggestion, looks simple and effective. :)

Jose Reyero’s picture

I think the part you guys overlooked in #18 is how much easier is to run with a manually uploaded language file (as compared to download, place in a server folder, etc..).

However I see we may not need that at all if there's an option to download from the server, I mean if the "Instructions for how to install in a different language" go away for good (Otherwise these are really not "human friendly" nor readable nor doable).

Also I agree with @Bojhan about the select list issue and it being an usability bug -- Even if Apple does it that way :p

So, ok with simplifing it just adding a help text and link.

YesCT’s picture

@Sutharsan would it help if @Jose Reyero or someone summarized the latest approach proposed?
Or are you all set and we'll wait for something to review? (No pressure, just wondering what you need.)

Sutharsan’s picture

@YesCT, I think I got a picture of the consensus. I will make and share a flow diagram before I start coding.

Sutharsan’s picture

This flow diagram (1. As discussed) should represent the above discussion. I added a second one (2. With special status for pre-loaded po files) because I think it was not discussed what to do with po which are in the translations directory before the language selection is started. For examples for distributions which bring their own po file(s). Should we still give use case a special treatment?
The (A and B) screens used in the flow diagram are included below.

locale-1848490-flow-diagram-26.png

Language selection including download text.
locale-1848490-language-selection-26A.png

Language selection when using local po files.
locale-1848490-language-selection-26B.png

Sutharsan’s picture

Issue summary: View changes

Updating todo's

Gábor Hojtsy’s picture

Hm, thanks for posting this. I've read this over the weekend and have been thinking about it for a while. I don't really have a strong opinion, not entirely sure if we should treat the "have locale files" and "have no local files, so we download it" case separately. A distro might have a .po file but people could still download others via the installer later. However, I see the use case of having a "safe" offline way of installing without the distractions of offerings that can only be done online. It would be lovely if others provided their perspectives as well :)

YesCT’s picture

I agree with

However, I see the use case of having a "safe" offline way of installing without the distractions of offerings that can only be done online.

I suggest instead treating the case totally different when there is a local .po file, that entries in the drop down get added for the local .po files, maybe with a marker like (local)

Keep the helptext in both cases, maybe with a tweak.

Also, I have a question: why is choosing English a special case? I think I could have an english translation .po file? ... or maybe not. English can be translated now, in the ui, right? I'm a bit confused about if that effects this.

English in the drop down, means "no translation"?

Gábor Hojtsy’s picture

There is no remote English translation, so unless you have local English file, it will mean no translation and the language related modules will not be enabled/set up. I don't think we covered/considered yet the case that you might have a local English file and that should enable the language system on installation. That is a separate issue IMHO :)

Sutharsan’s picture

@YesCT: yes, English means not translated, means no translation will be downloaded.

Bojhan’s picture

We might be designing it a little bit to "special", I understand we would like to inform the user but they probably wouldn't understand. If you have an internet connection then there is no value in providing this information, remote or local - the user doesn't have to know - to effectively use this functionality.

For distro's and/or no internet connection, we might need to do something special. E.g. for no internet connection, we might want to limit the list if there is none (tricky) or just have a really well informing error message. Distro's probably want the ability to limit the list, e.g. if you are specifically targeting some local market, at the very least the API's should allow for that - but this can be scope creep and solved in another issue.

Gábor Hojtsy’s picture

I agree distro control would be good, I opened this issue for that last (2011) November: #1351352: Distribution installation profiles are no longer able to override the early installer screens. Need people with actual interest there :)

Sutharsan’s picture

@bojhan, for some an online/offline check without prior consent is evil. See the discussion above about 'phone home'. I see no other way to determine online state than a phone home, that's how we got to this select English to opt-out.

Sutharsan’s picture

I'm working on the code for the workflow and find out that we add 4 (!) more points of failure: Can not create translations directory, translations directory is not writable, translation file not available at the translation server, no internet connection. This probably requires a full 'Verify requirements' step.

Sutharsan’s picture

Current core can not be installed in a non English language. I've created #1864292: Installation in non-English language fails which is blocking this issue.

Sutharsan’s picture

This is work in progress code!
The patch adds a step to the installer to download a translation file. The step is still un-conditional and should be conditional on availability of a translation file and non-English language selected.

Sutharsan’s picture

Status: Needs work » Needs review
FileSize
26.87 KB
28.72 KB

With a little help ...

  • This is a working patch with importer working according to workfow 2. With special status for preloaded po files in #26. The workflow is slightly changed for fault handling. Fault handling is made similar to existing fault handling in the installer.
  • The code has only been tested with browser based installation (interactive), no drush or other non-interactive tests done yet.
  • Some todo's left, but nothing functional.
Sutharsan’s picture

Issue summary: View changes

Updated issue summary.

Sutharsan’s picture

Issue summary: View changes

Updated issue summary.

Sutharsan’s picture

  • To do's resolved.
  • Simplified code in install_select_language().
  • New function install_display_requirements() for both requirement tasks (verify requirements and download translations).
  • Modified install_import_translations() and install_import_translations_remaining() to match the new situation.
  • Changed descriptions in 'Choose language' task and on download requirements page.

Ready for testing!

Sutharsan’s picture

Issue tags: +sprint, +language-ui
YesCT’s picture

39 did not apply: error: patch failed: core/modules/locale/locale.bulk.inc:404

rerolled.

YesCT’s picture

1. localization

I tested the links (the localization.drupal.org to localize.drupal.org I fixed).

2. English

I tested this installing in English. worked great. both with and without internet.

3. have to manually create translations directory

Testing with internet picking a language:
get a requirements error.

lif-s01-create_translations_dir-2012-12-18_1833.png

I'm not sure why I have to manually create the sites/default/files/translations directory. The regular install can create sites/default/files. And this can create the translations directory if files already exists... so I think this should try and create files if it does not exist, and then try and create translations.

based off of system.install
I had it make the directory if it does not exist.

  // First attempt to create or make writable the files directory.
  file_prepare_directory($files_directory, FILE_CREATE_DIRECTORY | FILE_MODIFY_PERMISSIONS);
  // Then, attempt to create or make writable the translations directory.
  file_prepare_directory($translations_directory, FILE_CREATE_DIRECTORY | FILE_MODIFY_PERMISSIONS);

  // Get values so the requirements errors can be specific.
  if (drupal_verify_install_file($translations_directory, FILE_EXIST, 'dir')) {
    $readable = drupal_verify_install_file($translations_directory, FILE_READABLE, 'dir');
    $writable = drupal_verify_install_file($translations_directory, FILE_WRITABLE, 'dir');
    $translations_directory_exists = TRUE;
  }

It seemed like I should have been able to use the result from file_prepare_directory and simplified or eliminated the if below, but the if makes for really accurate messages in the requirements page, so I left it there.

4. '/files/translations'

I feel like this:

  $files_directory = variable_get('file_public_path', conf_path() . '/files');
  $translations_directory = variable_get('locale_translate_file_directory', conf_path() . '/files/translations');

should be

  $files_directory = variable_get('file_public_path', conf_path() . '/files');
  $translations_directory = variable_get('locale_translate_file_directory', $files_directory . '/translations');

and also that 'files' and 'translations' should be constants ... but that could be because I dont understand something ( #1869912: make files a const (as in /sites/default/files/*) )

5. always readable and writable true

    $readable = drupal_verify_install_file($translations_directory, FILE_READABLE, 'dir');
    $writable = drupal_verify_install_file($translations_directory, FILE_WRITABLE, 'dir');

does not work. $readable and $writable are always true if the directory exists.

Also, the requirement that says it's readable is not showing. Is that by design? The others show when they are green.

dif-s03-always_writable_true-2012-12-18_2142.png

I tried these instead:
$writable = is_writable($translations_directory);
$readable = is_readable($translations_directory);
they are also always true.

I'm going to say this is a separate problem and we should file a follow-up... wait. (see next point)

6. sets it to exactly the MASK

I figured out that drupal_verify_install_file($translations_directory, FILE_READABLE, 'dir');
sets it exactly to only that mask, it does not add that permission to what the directory already has.
That is why the check for is_readable was coming back true, because I had it intermixed ... like:

    $readable = drupal_verify_install_file($translations_directory, FILE_READABLE, 'dir');
$readable = is_readable($translations_directory);  
// Note at this point it *is* readable
    $writable = drupal_verify_install_file($translations_directory, FILE_WRITABLE, 'dir');
$writable = is_writable($translations_directory);
// But here it is only writable.

But install fix http://api.drupal.org/api/drupal/core%21includes%21install.inc/function/...
should be adding to the permissions already there...

So I'm confused.

7. It works

connected to the internet
shows the imported language right away
lif-s04-translates_right_away-2012-12-18_2230.png

8. with a file in translations locally

With a local file, in sites/default/files/translations
the drop down shows just english and the local file(s)
nice.
lif-s05-local_po-2012-12-18_2259.png

YesCT’s picture

+++ b/core/includes/install.core.incundefined
@@ -1271,26 +1256,26 @@ function install_select_profile_form($form, &$form_state, $install_state) {
+ *   An associative array of file uris keyed by language code. Uris as

uri -> URI

+++ b/core/includes/install.core.incundefined
@@ -1399,14 +1364,14 @@ function install_select_language(&$install_state) {
+ *   (option) An associative array of file information objects keyed by file URIs as

option -> optional

+++ b/core/includes/install.core.incundefined
@@ -1452,6 +1435,115 @@ function install_select_language_form($form, &$form_state, $files) {
+ * @param $install_state
...
+ * @return
...
+function install_download_translation(&$install_state) {

types needed

+++ b/core/includes/install.core.incundefined
@@ -1863,6 +2142,54 @@ function install_check_requirements($install_state) {
+ * @return
...
+function install_display_requirements($install_state, $requirements) {

needs types

Note: only the types might be blocking.
Note: I didn't read through the whole patch line by line. Me or someone should do that.

Gábor Hojtsy’s picture

Status: Needs review » Needs work

Patch looks good on a code review. I have some relatively minor remarks, maybe two are more involved:

+++ b/core/includes/install.core.incundefined
@@ -192,6 +193,10 @@ function install_state_defaults() {
+    // The server URL where the interface translations files can be downloaded.
+    // Tokens in the pattern will be replaced by appropriate values for the
+    // required translation file.
+    'server_pattern' => 'http://ftp.drupal.org/files/translations/%core/%project/%project-%version.%language.po',

"interface translation files" imho, no need to double pluralize. Not done elsewhere either AFAIS.

+++ b/core/includes/install.core.incundefined
@@ -1271,26 +1256,26 @@ function install_select_profile_form($form, &$form_state, $install_state) {
+ *   An associative array of file uris keyed by language code. Uris as
+ *   returned by file_scan_directory().

URIs (twice)

+++ b/core/includes/install.core.incundefined
@@ -1271,26 +1256,26 @@ function install_select_profile_form($form, &$form_state, $install_state) {
+    $langcode = preg_replace('!^(.+\.)?([^\.]+)$!', '\2', $file->name);
     // Language codes cannot exceed 12 characters to fit into the {language}
     // table.
-    if (strlen($files[$key]->langcode) > 12) {
-      unset($files[$key]);
+    if ($langcode <= 12) {
+      $translations[$langcode] = $uri;

$langcode is a string, and most (if not all) langcodes do not contain a number, so they will always be <= 12 (when type cast). I think you removed too much code here, and the strlen() should go back?

+++ b/core/includes/install.core.incundefined
@@ -1328,66 +1313,46 @@ function install_find_translation_files($langcode = NULL) {
+    // If we are performing a none interactive installation. If only one
+    // language (English) is available, assume the user knows what he is doing.
+    // Otherwise thow an error.

non-interactive (instead of none interactive).

+++ b/core/includes/install.core.incundefined
@@ -1415,21 +1380,38 @@ function install_select_language_form($form, &$form_state, $files) {
+    foreach ($standard_languages as $langcode => $language_names)
+    // Build a select list with available languages.
+    $select_options[$langcode] = $language_names[1];
+    // Build a list of languages required for browser detection.
+    $languages[$langcode] = new Language(array(
+      'langcode' => $langcode,
     ));

What does this foreach apply to?! It definitely does not follow code style for {} wrapping.

+++ b/core/includes/install.core.incundefined
@@ -1452,6 +1435,115 @@ function install_select_language_form($form, &$form_state, $files) {
+ * @return
+ *   A themed status report, or an exception if there are requirement errors.
+ *   If there are only requirement warnings, a themed status report is shown
+ *   initially, but the user is allowed to bypass it by providing 'continue=1'
+ *   in the URL. Otherwise, no output is returned, so that the next task can be
+ *   run in the same page request.

If there are exceptions thrown, we should document them with @throws I believe.

Also the continue=1 sounds like a hack documented here, and no users will see this doc obviously :) Not sure why would people do that?!

+++ b/core/includes/install.core.incundefined
@@ -1452,6 +1435,115 @@ function install_select_language_form($form, &$form_state, $files) {
+    // Prevent URIs with triple slashes when glueing parts together.
+    $path = str_replace('///', '//', "$destination/") . drupal_basename($parsed_url['path']);

I think "glueing" should be "gluing".

+++ b/core/includes/install.core.incundefined
@@ -1452,6 +1435,115 @@ function install_select_language_form($form, &$form_state, $files) {
+ *
+ * @param string $url
+ *  The URL to contact.
+ *
+ * @return string
+ *   URL of the server if the localization server was contacted successfully.
+ *   FALSE if not.
+ */
+function install_check_localization_server($url) {
+  $result = drupal_http_request($url, array('method' => 'HEAD'));

URLs are called URIs elsewhere :)

+++ b/core/includes/install.core.incundefined
@@ -1452,6 +1435,115 @@ function install_select_language_form($form, &$form_state, $files) {
+  // Calculate the major and minor release numbers to fall back to.
+  // e.g. 8.0-dev falls back to 7.0 and 8.2-dev falls back to 8.1.
+    if ($minor == 0) {

Incorrect indentation.

+++ b/core/includes/install.core.incundefined
@@ -1589,19 +1681,42 @@ function install_import_translations(&$install_state) {
+  // If a non-english language was selected, remove English and import the

Should probably be "non-English".

+++ b/core/includes/install.core.incundefined
@@ -1589,19 +1681,42 @@ function install_import_translations(&$install_state) {
+ * Tells the translation import process that drupal core is installed.

Drupal

+++ b/core/includes/install.core.incundefined
@@ -1651,20 +1766,29 @@ function install_configure_form($form, &$form_state, &$install_state) {
- *
- * @todo
- *   This currently does the same as the first import step. Need to revisit
- *   once we have l10n_update functionality integrated. See
- *   http://drupal.org/node/1191488.

WOOOOT!

+++ b/core/includes/install.core.incundefined
@@ -1728,6 +1852,161 @@ function _install_profile_modules_finished($success, $results, $operations) {
+  // Build the URL where the translation file and translation server can be
+  // downloaded from.

The translation server is downloaded?! :)

+++ b/core/includes/install.core.incundefined
@@ -1863,6 +2142,54 @@ function install_check_requirements($install_state) {
+function install_display_requirements($install_state, $requirements) {

Good work making a reusable function out of this :)

Sutharsan’s picture

Status: Needs work » Needs review
FileSize
11.61 KB
33.97 KB

Comments processed.

What does this foreach apply to?! It definitely does not follow code style for {} wrapping.

Made some changes to install_select_language_form() in comment, code and variable names. Hopefully the code is now easier to understand.

If there are exceptions thrown, we should document them with @throws I believe.
Also the continue=1 sounds like a hack documented here, and no users will see this doc obviously :) Not sure why would people do that?!

"@throws ..." added. Not sure either why people add "...continue=1 .." to the comment. I just copied it. But now removed my duplicate piece and left the original of this comment.

@@ -1872,15 +1859,14 @@ function install_check_translations($install_state) {
   file_prepare_directory($translations_directory, FILE_CREATE_DIRECTORY | FILE_MODIFY_PERMISSIONS);
 
   // Get values so the requirements errors can be specific.
-  if (drupal_verify_install_file($translations_directory, FILE_EXIST, 'dir')) {
+  if (drupal_verify_install_file($translations_directory, FILE_EXIST|FILE_WRITABLE, 'dir')) {

A change to harden the translation download checks. Copied this from the existing check in install_check_requirements().

Status: Needs review » Needs work

The last submitted patch, locale-install-import-1848490-45.patch, failed testing.

YesCT’s picture

Status: Needs review » Needs work

[edit: it was.] that should be an interdiff to the more recent patch (-43.patch which is in comment #42)

Gábor Hojtsy’s picture

Status: Needs work » Needs review
YesCT’s picture

Status: Needs work » Reviewed & tested by the community

I confused myself with messing up the comment numbers on the patch and interdiff.

The patch in #45 has the changes from #42 and the code/comment clean up from #44.

nice!

I also again tried it manually, and it installs nicely, creating the files dir and the translations dir and downloading and importing a language.

YesCT’s picture

Issue tags: -Usability, -D8MI, -sprint, -language-ui
YesCT’s picture

YesCT’s picture

YesCT’s picture

Status: Reviewed & tested by the community » Needs work

The last submitted patch, locale-install-import-1848490-45.patch, failed testing.

YesCT’s picture

Status: Needs work » Needs review
Gábor Hojtsy’s picture

Issue tags: +Usability, +D8MI, +sprint, +language-ui
YesCT’s picture

Status: Needs review » Reviewed & tested by the community
xjm’s picture

Title: Make installation process use automatically translation import » Import translations automatically during installation
Gábor Hojtsy’s picture

webchick’s picture

Really appreciate the efforts to keep this patch applying. I meant to sit down and review it today, but got struck down with a migraine which is still there. :\

I'll make every attempt to review this either later today or this weekend. Though this should not stop any other core committers from getting to it first! :)

Gábor Hojtsy’s picture

Issue tags: -Usability, -D8MI, -sprint, -language-ui
YesCT’s picture

Issue tags: +Usability, +D8MI, +sprint, +language-ui
YesCT’s picture

webchick’s picture

Status: Reviewed & tested by the community » Needs work
FileSize
322.93 KB
149.42 KB
57.06 KB

Ok, skull-splitting migraines are done, so are days of non-stop phone calls ;), time to review this baby!

#1: HOLY COW, IT WORKS!

Second screen of the installer, in French!

#2: ...almost. ;)

500 screenfulls of SQL error garbage.

Full error there is attached below as a .txt file. Basically, it seems to get stuck in some kind of loop forever, and the tail end is:

[:db_condition_placeholder_4549] => 4887 [:db_condition_placeholder_4550] => 4888 [:db_condition_placeholder_4551] => 4889 [:db_condition_placeholder_4552] => 4890 [:db_condition_placeholder_4553] => 4891 [:db_condition_placeholder_4554] => 4892 [:db_condition_placeholder_4555] => 4893 [:db_condition_placeholder_4556] => 4894 [:db_condition_placeholder_4557] => 4895 [:db_condition_placeholder_4558] => 4896 [:db_condition_placeholder_4559] => 4897 [:db_condition_placeholder_4560] => 4898 [:db_condition_placeholder_4561] => 4899 [:db_condition_placeholder_4562] => 4900 [:db_condition_placeholder_4563] => 4901 [:db_condition_placeholder_4564] => 4902 [:db_condition_placeholder_4565] => 4903 [:db_condition_placeholder_4566] => 4904 )

Conditions of my environment:
- Running Acquia Dev Desktop 7.18.17, PHP 5.3.18.
- Chose SQLite as the database type.
- Have installed D8 before.

Anyway, I'm dead in the water here so can't test further. :( Let me know if there's something I can do to help debug this further. If this is only occurring on my environment, I'll try some other things.

YesCT’s picture

seriously?!? *HA*

OK. What language was that btw? French?

Gábor Hojtsy’s picture

Status: Needs work » Reviewed & tested by the community

@Sutharsan did extensive mining around this issue and figured out (a) it **only happens with poor sqlite** (b) **it predates this issue**. @webchick: if you *do not apply* this patch and add French to your site with locale module enabled after installed in English fine on sqlite OR import a big .po file downloaded from localize.drupal.org on the locale interface manually, you'll see the exact same issue. It is in fact due to how the JS translation file rebuilding tries to optimize which files it needs to rebuild (instead of rebuilding them all as before).

So that issue predates this patch and is independent of it. @Sutharsan opened a separate issue for that and proposed a patch at #1884182: Import of large number of translations fails on SQLite.

That said, no issues found with this patch, so moving back to RTBC.

webchick’s picture

Status: Reviewed & tested by the community » Needs work
FileSize
14.15 KB

Ok, round two! Now that I figured out I need to do 127.0.0.1 instead of localhost for my DB host, onto MySQL testing instead. :D No more endless SQL errors, cool. :)

The first thing is that since I didn't clear my sites/8x.localhost/files/translations directory at first, I only got shown the options for either English or Français. Now, this is an edge case, since I shouldn't have done that anyway (the issue summary notes this) and wouldn't realistically hit this on a fresh installation (would I on an upgrade?), but it's interesting that if you get into that situation it seems you can't recover and get the full list of languages again.

One relatively minor thing is that the progress bar during translation import was confusing. The number on the bottom and the number on the right were counting up at two different speeds, and the bar only fills up to about 60% before taking me to the next screen. Seems to be some kind of math issue here?

Importing translations says 20%, progress bar says 44%

However, otherwise, it seems to work great! :D Under admin/config/regional/language the translation shows at 84.18%, and I don't have any idea what to click on for most things. ;)

I definitely came across #1848552: Toolbar icons disappear with translated menu, but moreover the toolbar items weren't translated for me at all for some reason. However, when I cleared cache this problem cleaned itself up. So it seems we missing a cache clear at some point before the installer completes.

So other than the goofy math issue and a missing clear cache, this looks good to go from me!

webchick’s picture

Hm, shoot. Unfortunately, I can't reproduce the infinite SQL messages of death in #64 without this patch. :( So if we commit this without #1677026: Less aggressive locale js file rebuilds or equivalent, we're introducing a critical bug to core. :(

YesCT’s picture

regarding the first point in #67

what to do when there exists a local .po file is discussed in #26-#32

If we decide to change that part, I think that can be a follow-up.

YesCT’s picture

I reproduced the sqlite issue in clean 8.x (just in mamp) http://youtu.be/UMoI6fjKBjc

steps:
sudo rm -r sites (to clear any config)
git checkout sites
git checkout 8.x (make sure on 8.x and it's clean/green)
git pull --rebase (just to be sure get the latest, it's changing fast these days)
drop database
install manually in the ui and pick sqlite
enable Interface Translation
go to configuration -> user interface translation
click import tab, follow link to translation server
pick french, scroll down on french page and get the 7.x .po file
back on the import tab, browse to select the french .po file
import
wait
see errors

so that is a sep issue.

that leaves:

goofy math issue and a missing clear cache
webchick’s picture

Yes, but the consequence of this patch is it prevents you from installing Drupal altogether on SQLite. The consequence of the existing bug is it won't let you download translations to an existing, working Drupal site.

webchick’s picture

So if nothing else, we need better exception handling here or something so the installer can recover from catastrophic failure like that.

Gábor Hojtsy’s picture

@webchick: sure you can install Drupal with sqlite, that is how the reproduction steps were produced in #70! With or without this patch, you cannot make an SQLite installed site use any other language but English (unless you manually split the translation file to chunks containing no less than 100 strings and import them one by one manually, which is a no-go). This patch makes the bug easier to reproduce (because it adds it in the installer), but the bug is "I cannot make an SQLite site use any other language but English on the UI" and that exists with or without this patch. If that is a critical bug, we should go and mark #1884182: Import of large number of translations fails on SQLite a critical.

YesCT’s picture

I think the batch is more than just importing the translations so that is part of why the percents do not match up. but as @webchick said, it's strange to suddenly finish when the percent on the right is at 59/60%.

related to: #1866544: Improve Locale batch progress and result messages ?

===

but, I cannot reproduce the need to clear the cache to see the translations in the toolbar (I tried french and spanish)

YesCT’s picture

to clarify, based on irc conversation with webchick:
the sqlite issue is already existing, but webchick would really like a fix/quick fix/work around to get this in.

maybe a try/catch ?

YesCT’s picture

Since it was not a quick fix: Follow-up filed:
#1884996: Progress of Import translations automatically during installation goes to warp speed at the end after 60%

Also could not reproduce needing to clear the cache in safari.
Per irc: chalking up to fluke. Let's see if others can reproduce and open a follow-up then if so.

Remaining: decide how to handle sqlite.

Gábor Hojtsy’s picture

Status: Needs work » Reviewed & tested by the community

Not going to introduce an SQLite-workaround here. The patch provided at #1884182: Import of large number of translations fails on SQLite should solve the overall problem without needing any workarounds for the installer specifically.

webchick’s picture

Category: bug » feature
Priority: Normal » Major
Status: Reviewed & tested by the community » Fixed

Awesome! Just installed with SQLite, and now see the following:

"Félicitations, vous avez installé Drupal !

Visitez votre nouveau site."

:D :D :D

The toolbar cache issue was some kind of issue on my end. I guess perhaps Safari hates the French and resists their attempts to enforce their language on navigation bars, or maybe is overly sentimental about the toolbar that used to be. :P #1884996: Progress of Import translations automatically during installation goes to warp speed at the end after 60% has been filed as a minor follow-up.

I'm actually going to re-categorize this as a major feature, because I don't see any possible world in which it's a bug. However, since it was RTBC well before blocks as plugins was committed, I am ok with committing it despite the fact that we are currently over thresholds.

Committed and pushed to 8.x. YEAH!

Gábor Hojtsy’s picture

Issue tags: -sprint

Woooooooot! :) Thanks Sutharsan, YesCT, this is a major milestone! People will praise your name for years to come :)

steinmb’s picture

Category: feature » bug
Priority: Major » Normal
Status: Fixed » Reviewed & tested by the community
Issue tags: +sprint
FileSize
30.7 KB

Took it for a spin on PostgreSQL 9.21. It seems to work just fine. The only issue I could find is that requirement message is a bit misleading.

1. At this point do we is is both files and translation missing. Not sure if new users get that they need to create both without us telling them this.

2. If the missing directories are created but apache lack write access do we still claim the directories are missing instead of telling the user that they do but we are lacking write access as we normally do.

Except from that is this fantastic work! :)

aspilicious’s picture

I got a problem on windows. http://drupal.org/node/1885510

webchick’s picture

Category: bug » feature
Priority: Normal » Major
Status: Reviewed & tested by the community » Fixed

I think #80 might've been a cross-post? Or at least RTBC doesn't make sense for this issue because there's nothing to commit. :)

Moving back to fixed, but could we make sure follow-up(s) gets filed for #80 and cross-linked here?

Gábor Hojtsy’s picture

@steinmb: it might be simplest if we can couple your issue with #1885510: Can't install on some systems (like windows) due to folder permissions (executable check not needed) (ie. expand the scope of that a bit), since that is about making requirements messaging cleaner and possibly removing extraneous ones.

steinmb’s picture

Obs. cross-post and I did not mean to change the issue status.

@gabor: I'll post those finding into that issue, they are sort of related (sort of).

Gábor Hojtsy’s picture

Issue tags: -sprint

Restore sprint-less state :)

Status: Fixed » Closed (fixed)

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

YesCT’s picture

#26 to #32 and some other later comments are us deciding how to handle local files and their effect on the installer, which #1974048: Limited display of languages when going back in installer is confusing finds confusing.

YesCT’s picture

Issue summary: View changes

Updated issue summary.

bhaskar-chakraborty’s picture

You can easily use the below update hook to import your PO file which is in
default/sites/module/translation/ folder

function es_order_update_N() {

require_once 'includes/locale.inc';
$languages = language_list();
// Try to allocate enough time to parse and import the data.
drupal_set_time_limit(240);
foreach (file_scan_directory(drupal_get_path('module','es_order'), '/.*\.po$/') as $file) {
$langcode ='fr';
$status = _locale_import_read_po('db-store', $file, LOCALE_IMPORT_OVERWRITE,'fr');
if ($status === FALSE) {
// Error messages are set in _locale_import_read_po().
continue;
}
// Get status information on import process.
list($headerdone, $additions, $updates, $deletes, $skips) = _locale_import_one_string('db-report');

if (!$headerdone) {
drupal_set_message(t('The translation file %filename appears to have a missing or malformed header.'), 'error');
}
drupal_set_message(t('The translation was successfully imported. There are %number newly created translated strings, %update strings were updated and %delete strings were removed.',array('%number' => $additions,'%update' => $updates,'%delete' => $deletes)),'status');
watchdog('locale', 'Update Hook Fired');
}

}