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
- Check-out the latest Drupal 8.x-dev.
- Apply the latest patch from this queue.
- To test without pre-installed po files: make sure your sites/*/files/translations directory is empty
- Start the installation: example.com (or example.com/install.php)
- Choose English or a non-English language (go wild here ;) )
- 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.
Comment | File | Size | Author |
---|---|---|---|
#80 | Requirements problem | Drupal.jpg | 30.7 KB | steinmb |
#67 | weird-progress-bar.png | 14.15 KB | webchick |
#64 | Screen Shot 2013-01-08 at 11.38.42 PM.png | 57.06 KB | webchick |
#64 | Screen Shot 2013-01-08 at 11.49.15 PM.png | 149.42 KB | webchick |
#64 | full-error.txt | 322.93 KB | webchick |
Comments
Comment #1
Sutharsan CreditAttribution: Sutharsan commentedA first, and still dirty, patch which introduces the automatic translation import to the installer. The patch depends on #1804688: Download and import interface translations.
Comment #1.0
Sutharsan CreditAttribution: Sutharsan commentedSummary updated with 'todo'
Comment #2
Sutharsan CreditAttribution: Sutharsan commentedA 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.
Comment #3
YesCT CreditAttribution: YesCT commentedI'm testing this now. I'll post results in a bit.
Comment #4
YesCT CreditAttribution: YesCT commentedWithout the patch:
and
Comment #5
YesCT CreditAttribution: YesCT commentedOverview
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
02 drop down has the languages. very nice.
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.
04 requirements (still in english)
05 set up database (still in english)
06 installation profile, modules installing (still in english)
07 new in the list of steps: set up translations (in english still)
08 configure site (in spanish!)
at first I thought this was still in english, but when I looked at the error closer...
I saw it's in spanish! cool.
About error: also seen in #1804688-67: Download and import interface translations screenshot s06b.
08b
09 Finished screen
10 Visit Site
It's in spanish! and no langcode in the url. nice.
11 more nice things: configuration admin page shows languages and ui translation (locale) already enabled
12 more nice things: there is no english language
13 more nice things: I could add english
14 more nice things: detection and selection working as expected
15 more nice things: can verify locale and language modules were enabled for me
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.
Comment #6
YesCT CreditAttribution: YesCT commentedThe icons in the new toolbar are not shown (except for Extend) in another language (... just checked spanish).
Is this an unrelated follow-up?
English:
Spanish:
Comment #7
Gábor Hojtsy@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 :)
Comment #8
YesCT CreditAttribution: YesCT commentedNeeds work, to make all the screens after language selection in that language.
That would be starting with step 3 in #5.
Comment #9
Sutharsan CreditAttribution: Sutharsan commented@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.
Comment #10
Gábor HojtsyComment #11
Gábor HojtsyLooking 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).
Comment #12
Jose Reyero CreditAttribution: Jose Reyero commentedThe 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.
Comment #13
Gábor HojtsyComment #14
Gábor HojtsyComment #15
Gábor HojtsyTL;DR: probably needs more discussion, don't delve into implementation yet :)
Comment #16
Sutharsan CreditAttribution: Sutharsan commented@gaborhojtsy, @reyero, any update on your discussion? This issue is next on my list.
Comment #17
Gábor Hojtsy@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 :)
Comment #18
Jose Reyero CreditAttribution: Jose Reyero commentedI'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..."
Comment #19
Gábor Hojtsy@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.
Comment #20
Bojhan CreditAttribution: Bojhan commentedChanging 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?
Comment #21
Gábor HojtsyI 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.
Comment #22
Gábor HojtsyOh, and I do like that suggestion, looks simple and effective. :)
Comment #23
Jose Reyero CreditAttribution: Jose Reyero commentedI 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.
Comment #24
YesCT CreditAttribution: YesCT commented@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.)
Comment #25
Sutharsan CreditAttribution: Sutharsan commented@YesCT, I think I got a picture of the consensus. I will make and share a flow diagram before I start coding.
Comment #26
Sutharsan CreditAttribution: Sutharsan commentedThis 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.
Language selection including download text.
Language selection when using local po files.
Comment #26.0
Sutharsan CreditAttribution: Sutharsan commentedUpdating todo's
Comment #27
Gábor HojtsyHm, 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 :)
Comment #28
YesCT CreditAttribution: YesCT commentedI agree with
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"?
Comment #29
Gábor HojtsyThere 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 :)
Comment #30
Sutharsan CreditAttribution: Sutharsan commented@YesCT: yes, English means not translated, means no translation will be downloaded.
Comment #31
Bojhan CreditAttribution: Bojhan commentedWe 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.
Comment #32
Gábor HojtsyI 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 :)
Comment #33
Sutharsan CreditAttribution: Sutharsan commented@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.
Comment #34
Sutharsan CreditAttribution: Sutharsan commentedI'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.
Comment #35
Sutharsan CreditAttribution: Sutharsan commentedCurrent 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.
Comment #36
YesCT CreditAttribution: YesCT commentedfound this #1864472: Warning when tries to delete English after non-English install, locale_translation_status_delete_languages()
while testing the patch on #1864292: Installation in non-English language fails
Comment #37
Sutharsan CreditAttribution: Sutharsan commentedThis 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.
Comment #38
Sutharsan CreditAttribution: Sutharsan commentedWith a little help ...
Comment #38.0
Sutharsan CreditAttribution: Sutharsan commentedUpdated issue summary.
Comment #38.1
Sutharsan CreditAttribution: Sutharsan commentedUpdated issue summary.
Comment #39
Sutharsan CreditAttribution: Sutharsan commentedReady for testing!
Comment #40
Sutharsan CreditAttribution: Sutharsan commentedComment #41
YesCT CreditAttribution: YesCT commented39 did not apply: error: patch failed: core/modules/locale/locale.bulk.inc:404
rerolled.
Comment #42
YesCT CreditAttribution: YesCT commented1. 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.
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.
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:
should be
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
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.
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:
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
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.
Comment #43
YesCT CreditAttribution: YesCT commenteduri -> URI
option -> optional
types needed
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.
Comment #44
Gábor HojtsyPatch looks good on a code review. I have some relatively minor remarks, maybe two are more involved:
"interface translation files" imho, no need to double pluralize. Not done elsewhere either AFAIS.
URIs (twice)
$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?
non-interactive (instead of none interactive).
What does this foreach apply to?! It definitely does not follow code style for {} wrapping.
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?!
I think "glueing" should be "gluing".
URLs are called URIs elsewhere :)
Incorrect indentation.
Should probably be "non-English".
Drupal
WOOOOT!
The translation server is downloaded?! :)
Good work making a reusable function out of this :)
Comment #45
Sutharsan CreditAttribution: Sutharsan commentedComments processed.
Made some changes to install_select_language_form() in comment, code and variable names. Hopefully the code is now easier to understand.
"@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.
A change to harden the translation download checks. Copied this from the existing check in install_check_requirements().
Comment #47
YesCT CreditAttribution: YesCT commented[edit: it was.]
that should be an interdiff to the more recent patch (-43.patch which is in comment #42)Comment #48
Gábor Hojtsy#45: locale-install-import-1848490-45.patch queued for re-testing.
Comment #49
YesCT CreditAttribution: YesCT commentedI 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.
Comment #50
YesCT CreditAttribution: YesCT commented#45: locale-install-import-1848490-45.patch queued for re-testing.
Comment #51
YesCT CreditAttribution: YesCT commented#45: locale-install-import-1848490-45.patch queued for re-testing.
Comment #52
YesCT CreditAttribution: YesCT commented#45: locale-install-import-1848490-45.patch queued for re-testing.
Comment #53
YesCT CreditAttribution: YesCT commented#45: locale-install-import-1848490-45.patch queued for re-testing.
Comment #55
YesCT CreditAttribution: YesCT commented#2: locale-install-import-1848490-2-for-testbot.patch queued for re-testing.
Comment #56
Gábor Hojtsy#45: locale-install-import-1848490-45.patch queued for re-testing.
Comment #57
YesCT CreditAttribution: YesCT commentedComment #58
xjmComment #59
Gábor Hojtsy#45: locale-install-import-1848490-45.patch queued for re-testing.
Comment #60
webchickReally 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! :)
Comment #61
Gábor Hojtsy#45: locale-install-import-1848490-45.patch queued for re-testing.
Comment #62
YesCT CreditAttribution: YesCT commented#45: locale-install-import-1848490-45.patch queued for re-testing.
Comment #63
YesCT CreditAttribution: YesCT commentedrelated #1703346: Make install system more translatable
Comment #64
webchickOk, skull-splitting migraines are done, so are days of non-stop phone calls ;), time to review this baby!
#1: HOLY COW, IT WORKS!
#2: ...almost. ;)
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:
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.
Comment #65
YesCT CreditAttribution: YesCT commentedseriously?!? *HA*
OK. What language was that btw? French?
Comment #66
Gábor Hojtsy@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.
Comment #67
webchickOk, 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?
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!
Comment #68
webchickHm, 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. :(
Comment #69
YesCT CreditAttribution: YesCT commentedregarding 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.
Comment #70
YesCT CreditAttribution: YesCT commentedI 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:
Comment #71
webchickYes, 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.
Comment #72
webchickSo if nothing else, we need better exception handling here or something so the installer can recover from catastrophic failure like that.
Comment #73
Gábor Hojtsy@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.
Comment #74
YesCT CreditAttribution: YesCT commentedI 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)
Comment #75
YesCT CreditAttribution: YesCT commentedto 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 ?
Comment #76
YesCT CreditAttribution: YesCT commentedSince 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.
Comment #77
Gábor HojtsyNot 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.
Comment #78
webchickAwesome! 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!
Comment #79
Gábor HojtsyWoooooooot! :) Thanks Sutharsan, YesCT, this is a major milestone! People will praise your name for years to come :)
Comment #80
steinmb CreditAttribution: steinmb commentedTook 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! :)
Comment #81
aspilicious CreditAttribution: aspilicious commentedI got a problem on windows. http://drupal.org/node/1885510
Comment #82
webchickI 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?
Comment #83
Gábor Hojtsy@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.
Comment #84
steinmb CreditAttribution: steinmb commentedObs. 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).
Comment #85
Gábor HojtsyRestore sprint-less state :)
Comment #87
YesCT CreditAttribution: YesCT commented#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.
Comment #87.0
YesCT CreditAttribution: YesCT commentedUpdated issue summary.
Comment #88
bhaskar-chakraborty CreditAttribution: bhaskar-chakraborty commentedYou 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');
}
}