Adding a language help page during installation is incorrect

When I go to http://drupal.org/project/translations and filter by core compatibility, there are only two projects with 7.x versions. Downloading them, I get a tarball which I can unpack in my root directory, just like before.

Neither of them work correctly, but that's probably just because they aren't complete? AFAIK, it is up to the packaged translation to make sure it puts something in profiles/translations (or wherever the correct destination is) when the tarball is unpacked.

How this all works with localize.drupal.org, that I'm not sure of.

+++ includes/install.core.inc	26 Aug 2010 22:20:13 -0000
@@ -1207,8 +1207,12 @@ function install_select_locale(&$install
+          $output .= '<ul><li>' . st('Determine if <a href="@translations" target="_blank">a translation of this Drupal version</a> is available in your language of choice. A translation is provided via a translation package; each translation package enables the display of a specific version of Drupal in a specific language. Not all languages are available for every version of Drupal.', array('@translations' => 'http://localize.drupal.org/')) . '</li>';

Maybe it's better to link to http://localize.drupal.org/translate/languages so people see which languages are available?

Powered by Dreditor.

+++ includes/install.core.inc	26 Aug 2010 22:20:13 -0000
@@ -1207,8 +1207,12 @@ function install_select_locale(&$install
+          $output .= '<ul><li>' . st('Determine if <a href="@translations" target="_blank">a translation of this Drupal version</a> is available in your language of choice. A translation is provided via a translation package; each translation package enables the display of a specific version of Drupal in a specific language. Not all languages are available for every version of Drupal.', array('@translations' => 'http://localize.drupal.org/')) . '</li>';

Better to use http://localize.drupal.org/translate/projects/drupal as a link.

Maybe change the wording of 'Not all languages are available for every version of Drupal' to 'Not all languages are available for this version of Drupal' or to 'Not all languages might be available'

+++ includes/install.core.inc	26 Aug 2010 22:20:13 -0000
@@ -1207,8 +1207,12 @@ function install_select_locale(&$install
+          $output .= '<ol><li>' . st('Download the language file from <a href="@translations" target="_blank">the translation server</a>,', array('@translations' => 'http://localize.drupal.org/')) . '</li>';

Maybe link directly to http://ftp.drupal.org/files/translations/7.x/drupal/

I'm wondering if it's possible to make this even easier, so people can actually directly download the right file ..., see #895202: Easier way to download

Powered by Dreditor.

I'm pretty convinced this is a critical usability bug. There doesn't seem to be any relationship between the instructions in D7 and the reality on localize.drupal.org. So, either the instructions or the reality need to change :)

I still don't understand what's going on overall in the sense that (a) localize.drupal.org doesn't yet seem to have a way for end users to download language files in the format that the installer and other parts of Drupal 7 (or Drupal 6 for that matter) expect them, (b) doesn't yet have a user friendly download interface, and (c) says on its very own FAQ page (http://localize.drupal.org/faq): "Q: Where do I get translations for Drupal, modules, themes and install profiles? A: For now, your definitive sources are the Drupal.org projects. Drupal core translations have their own projects under http://drupal.org/project/translations ...."

So the website is under development and isn't ready to be the definitive source yet and says so, but drupal.org itself is already linking to it as if it is - seems like a mistake?

Leaving this in the core queue for now, though. At least that will get it some attention.

Going through questions here:

- The installer translations need to be in profiles/$profilename/translations/*.po because the kind of interface displayed depends on the install profile; it might ask different questions, alter forms, etc. Many profiles do that. So having .po files in the Drupal root or somesuch does not really work as a general rule.

- Indeed, http://drupal.org/project/translations (and CVS/git management altogether) is being phased out to manage translations and localize.drupal.org is the definitive source. There is a download wizard planned for localize.drupal.org itself, given it is not exactly easy to start downloading stuff for a language if you don't know the project(s) you need translations for. Translations are organized by projects. So what we did before is we cross-linked the translation downloads from each project page on drupal.org (see among project links) as well as provided download links per branch on the project pages on l.d.o. Ideally we'd have a wizard where you can enter your project name and language and get redirected to the file or file list properly. Help in building this tool is appreciated: #897118: Build a translations download wizard / UI

- Now that translations are decoupled from projects on d.o, if you run 50 modules and need 3 languages on the site, you'll need to download 3*50=150 .po files. That clearly is a no-go. So we built the http://drupal.org/project/l10n_update tool, which was intended for core, but you know there was this feature freeze a year ago...

- Finally, l10n_update will not help people when downloading translations on installation, so we have http://drupal.org/project/l10n_install planned out which would be the install profile support for multilingual installs. I'd suggest telling people to download that profile once it is there, or even its full built Drupal included build altogether if they want translated Drupal out of the gate. This is not at all ready yet, once again, help is welcome.

In short, as with many things, we have some cool things planned out, but need help, so we are not ready yet entirely to tell everybody to use these. However, we do not put in more effort into the old processes and systems, so its an odd game suggesting either one :) Ultimately people should flock to the new ways of doing things, help build the missing parts and hammer out the bugs :)

This belongs to the Locale queue.

@aschiwi: well, ideally l10n_install could be built out to actually work and then it would be the ultimate install profile for any localized community. Its not a far shot. We had people in Paris(!) sprinting for that back in 2009. The group assembled there was temporary though and contributors were not lasting to the efforts :| Looks like we need more people to be upset enough about it to help and contribute.

Hm. So what's the answer for Drupal 7 beta 1, which will be out sometime in the next few weeks (we hope)? It sounds like we need to document the current method now and then knowingly break string freeze sometime in the future to point at the new way once all the various plumbing is in place. So does this effectively make this issue "postponed"?

Thanks, Gábor.

I'm still a little confused about how the installer and core files will work (since core itself is one "project" but has - or at least had - tons of .po files, right?). And what if you want to use one of the core profiles (i.e., the Standard profile, with all the features it adds) but also translate it - http://drupal.org/project/l10n_install wouldn't help with that... seems like you would still need to download and use the .po file for that profile itself.

In short, as with many things, we have some cool things planned out, but need help, so we are not ready yet entirely to tell everybody to use these.

Does that mean it's a problem that many places on drupal.org (including most prominently the "Translations" link on the front page) already are linking to localize.drupal.org? If so, maybe there should be an issue to switch that back for the moment. It affects people using Drupal 6 also.

I think we have to solve this somehow before releasing Drupal 7, I personally think it will be a big plus for Drupal if a person can easily install Drupal 7 standard in his/her own language without having them to click for 5-10 minutes, downloading several files, renaming and uploading them to the right place.

On the other hand I understand Gabor's explanation in #8 about how the translation is organized technically, but I wonder if it isn't possible to make this a bit easier for Drupal core, like for example allowing the translation to be in the root directory and/or the profiles directory so people don't have to first find out which profile they want to use before being able to select the right folder.

Another solution coulb be to provide localized downloads of Drupal 7 so people get English and their own language, but I cannot estimate how much work this will be. If it's managable then we probably could do the same for all profiles and modules

@David_Rothstein: yes, ideally all core profiles would have language support. We sprinted for this goal at Drupalcon Paris, when localize.drupal.org was the new kid on the block, but it was already clear that we need to change several processes on the infrastructure. I talked to Dries about a feature freeze exception, but since localize.drupal.org was not around much before the con, I think he felt it hard to argue for and said if we can accomplish stuff at the sprint, we can get these new things in. We did accomplish some, but far from as much as needed. You know Drupal 7 is in an announced feature freeze for the past year, so since there was no opportunity to get this into core, we worked on the server side and building out client tools in contrib instead.

Even though Drupal 7/6 can be in feature freeze, infrastructure needs to move on to better support contributors, so using version control by human intervention is being phased out for translations. The git migration is going to *deny* committing .po files to git to avoid this confusion, and that is still into the lifetime of Drupal 6 and definitely Drupal 7. So once again, while the new ways might not be entirely ready yet, they should be properly built out instead of putting more effort into trying to support a dying method.

Ideally, this feature would have gotten a feature freeze exception a year ago, but it did not. However, now it does not look like a long shot to build this out in contrib and fix for Drupal 6 and 7 via a distribution. Since there was not much interest to build this into core at the right time, distros will step in to solve this problem. I think this is even a generic answer to many issues around Drupal nowadays, so would not say it is shocking. It is definitely unfortunate that interest was missing to get this into core when it was still possible, I'm all for having this in core, but it needs several changes to how it handles language files that is not anymore possible to accomplish in a feature freeze. If l10n_install is properly built out, Drupal.org will need to do a better job at directing people to this distro to install localized versions. Like you get redirected to different downloads for Firefox when you need it localized.

@Gabor so can you patch for how to do it? Even it counts for tomorrow, we should just fix this text - the best way we know how, and that is accounting for future changes.

I'm still totally lost. :\ What textual changes do we need to make to the installer to close this critical, given that we have to deal with reality and not "what we wish reality would be if only stuff had come into place in time"?

@aschiwi: Just tested your patch.

Unfortunately linking to localize.drupal.org at the moment just adds confusion. When we say: "Download the language file from the translation server" and link to localize.drupal.org, there are two links there labeled "Download".
- The one leads to http://drupal.org/download, where the user can download Drupal core but NO language files.
- The other one leads to http://localize.drupal.org/download, an explanation page with also no way to download a language file.

The only place where a user can find a direct download link to a current translation file at the moment is http://ftp.drupal.org/files/translations/7.x/drupal/

Placing this link in your patch leads to a "doable" (from a user's point of view) multilanguage installation.

Patch with the new link and screenshot of confusing l.d.o. page attached.

I don't know if and when l.d.o will change, but for the moment, this should work.

bot

Releasing Drupal 7.0 without there being an easy way to install it in a different language is not an option.

I've heard following options to get there in this issue:

-> 1. Clicking a link on the Drupal download page saying "Download Drupal in other languages" and knowingly or not knowingly installing l10n_install which is simply Drupal in your language.

That counts as easy as long as the Navigation on Drupal.org is intuitive. But we can control that. It seems to be able to download a distro which contains translations #644916: Add drush make command for pulling core installer translations from l.d.o needs to happen. As soon as that is done, we could at least make l10n_install contain all translations for now, even if that is not the best thing in the world.

-> 2. Downloading something from localize.drupal.org manually, renaming it, creating new folders in the Drupal directory and uploading the renamed file into the new directory.

That is not easy!!! Not with the best help text in the world!!! There are a million things that you can do wrong. And for people on shared hosting uploading a file is definitely possible, but might or might not be easy in terms of effort.

(Simply mentioning for completeness)
-> 3. Simply install Drupal, because l10n_install has been committed to core.

Very easy, actually, but not going to happen.

Are there other ones? Since 2. and 3. are out, we should postpone this issue on #644916: Add drush make command for pulling core installer translations from l.d.o if 1. is really our only option.

Can we have a screenshot of the proposed change to the help text? Makes it easier to review,

Look, it is not exceptionally hard to make l.d.o *also* generate the old style tar.gz translation files with many small files for core, so people could use their old habits to download that file, extract into Drupal core (with the usual caveats that it overwrites stuff on the Mac, and needs careful attention), etc. The reason we don't do that currently is that:

1. We are aiming to have people use modules act as clients to download these, and we could not historically rely on tgz support being there at all times (although the current update module code has built-in PHP level tgz support, right?).

2. With a module downloading stuff, having those small files to work with can be more pain then gain (eg. repeated strings will be in multiple files).

3. This still does not solve anything for contrib. Historically, contrib modules included .po files. This is not the case anymore for D7 and D6 alike. This change is not new to D7. D6 users will need to be re-educated too. Think if you run 50 modules and need 3 languages on the site, you'll need to manually download 50x3=150 translation files. Not likely you'll do this manually. So we need to have this tool on your site anyway. Why not unify the core process and do it from the start then?

All-in-all, ultimately we put time into making something close to the old ways work to some degree with core but those gonna be very limited anyway.

@Gabor:

Historically, contrib modules included .po files. This is not the case anymore for D7 and D6 alike. This change is not new to D7. D6 users will need to be re-educated too.

Can you give us a link to where this new behavior is described?

@Bojhan: The screenshot for the changes from #3 and #19 is attached. The only difference between the two is in the link behind "from the translation server", which is not visible in the screenshot.

@reglogge: yes, it is mentioned in http://localize.drupal.org/faq, explained in various sessions of which slides and videos are continually posted at http://localize.drupal.org/news (also syndicated to Drupal Planet). Eg. the latest news post on there included this paragraph:

Given localize.drupal.org's success to unseat CVS as the de-facto storage for translations, the git migration plans do away with handling .po files in version control altogether. (At least as far as human managed version control goes). We need a unified place to go for translations, and scattered, duplicated efforts don't do our translators and users favors.

Okay then we have

-> 4. Make localize.drupal.org spit out D6-style tarballs and have users download those and extract them.

Which is not really an option, because it is essentially a waste of effort in the long run. Also, people still have to FTP up those files (just like in D6). With #644916: Add drush make command for pulling core installer translations from l.d.o we could just let them download the correct code in the first place.
I still stand by postponing this issue on that one.

Regarding webchick's comment in #17:

What textual changes do we need to make to the installer to close this critical

The patch in #19 makes these textual changes with the result that installing Drupal in another language is at least doable, if not really convenient.

Without the patch, we are misleading users.

Finding a better way of installing in another language according to the suggestions in #21 and/or #27 should definitevely be pursued in a follow-up issue.

Postponing this issue in the face of a clear error during our installation process should not be an option IMHO.

So, if there's no time for a systematic solution, let's focus on the user and the critical(!) issues at hand, and just make sure that the text is correct (and doesn't confuse/mislead the user!).

Actually one file is not enough for translation! So this text is leading to confusion.

User need at least [lang].po file for install profile then a set of files for modules, themes and etc

I've just downloaded a "Drupal 7 core package format (translations directories)" - screenshot shows contents

OTOH exporting all-in-one file could lead to memory or time-limit issues on most hostings.

@andypost: No, I don't think the text leads to confusion.
At http://ftp.drupal.org/files/translations/7.x/drupal/ (the link given in the revamped text) there are only one-file translations. These can be renamed to de.po or fr.po or ru.po and then be placed into /profiles/standard/translations - afterwards the installation works just fine.

The problem with the current situation on localize.drupal.org is that there are multiple formats in which you can download a translation (core package format, all in one file, with different grades of verbosity and fuzzyness), all of which is highly confusing for novice users.

Again: The current way of adding a language during installation is far from perfect and should surely be improved. However, this issue should only deal with the *at this moment* wrong instructions we give users. That should be corrected now.

Whooah! This just in: http://localize.drupal.org/node/1909

Need to re-evaluate this issue...

@reglogge: yes, I was working on that better download exposure feature in the light of this issue; the exports are *not at all* geared towards novice users and with the l10n_update module, we are cutting down the multiple-small file exports there even. Users (vs. contributors) should use the download features available for everybody, only team members (=contributors) should use the export tool.

Ok, rerolled the patch with links to http://localize.drupal.org/translate/downloads, since this is the most logical and convenient place for end-users to go and find translation packages.

@Gabor Hojtsy: Some improvements could be made to the landing page http://localize.drupal.org/translate/downloads. Where to report these?

I also noted that the "confusing" download links on http://localize.drupal.org that I mentioned in #31 are visible only for users with an account on l.d.o., which is a good thing!

To sum this up, here is a current screenshot of the proposed change to the installer screen.

#644916: Add drush make command for pulling core installer translations from l.d.o has seen some commits lately. Even though it is not the cleanest solution yet (due to the fact how localize.drupal.org generates .po files) it is now possible to include translations in drush-make-generated builds with the --translations flag (see here for more info). So the additional work for drupal.org to provide downloads which already contain the language in the correct place is minimal.
Hence, for the usability of thousands of non-English people who will download Drupal 7, I want to explicitly discourage to commit this patch and open a new issue in the infrastructure queue that discusses how to make the translated build using Drush Make. Then instead of this giant wall of text, which newbie users are bound to get wrong somewhere, we could just link to http://drupal.org/drupal/localize or http://localize.drupal.org/download-drupal or whatever it will be.

I agree since the state of how translated Drupal builds will be built is still in flux, it is probably best not to include detailed instructions but to point out to a living document on d.o.

So can we get a document up and a patch for pointing to that documens. This thing has no reason to be in the critical queue if there is such an obvious fix - but no one is willing to actually do it.

The install fails on translation because drupal is checking for a file called install.inc in database subdirectories.

Since you add a folder called translation with a *.po file in it - and nothing else - debugger report:

Compile Error: /html/includes/database/database.inc line 2121 - require_once(): Failed opening required '/html/includes/database/translations/install.inc'

simply remove the includes/database/translations directory and you will be able to install it :-)

Hmmm. That sounds suspiciously like a DBTNG bug that was fixed recently.

Does that still happen in HEAD? (aka today's 7.x-dev, not alpha6)

I took this one out of the Drupal queue and said it belonged in the Chinese Simplified queue:
#908456: Installing in chinese fails at step 3: Verify requirements

Then I figured I'd take my own suggestion and install in Spanish or something, but I couldn't figure out how to. So just wanted to cross-reference the issue I took away...

I created http://drupal.org/node/909138 and tried to document the steps to install in another language but couldn't get it to work.

todo:
- Make installing in another language work ;-)
- Write up the how-to on http://drupal.org/node/909138
- Create an alias for http://drupal.org/node/909138 (another issue in the web masters queue?)
- Create the patch that makes the installer point to this alias.

I tried to look into l10n_server to see what maybe could be done, and saw that basically l10n_server does support automatically exporting projects in the Drupal core format (translations directories). I think it would be really helpful if Gábor Hojtsy could summarize where the problems in the process currently lie and concrete points that can be worked on.

aschiwi: thanks, latest patch works indeed. It's a cumbersome but it works. I added a reworked version of the instructions in that patch to http://drupal.org/node/909138. The patch in here could now focus on removing this instructions page and make the link on the 'Choose profile page' point to the handbook page:

Can we agree on "http://drupal.org/drupal/localize" as the alias we want to use?

Why not just http://drupal.org/localize?

@tstoeckler: I think I answered those questions about two weeks ago in #23 above. Any specific questions based on / beyond that?

I opened #909768: Create alias 'drupal.org/localize'

#46: The attached patch does 2 things.

- moves the link "Learn how to install Drupal in other languages" to the profile selection page (provisionally pointing at http://drupal.org/node/909138).
- removes the previous help text.

I don't know if this is enough, but the installation worked both with no additional language installed as well with additional languages.

ok, here is the same patch as in #55, only with the link pointing to http://drupal.org/localize, which has been created in #909768: Create alias 'drupal.org/localize'.

To summarize:
- The link "Learn how to install Drupal in other languages" is now placed on the profile selection page.
- If the users follows the directions on drupal.org/localize and downloads a translation file, in the next step he lands on the language selection page.
- If the user doesn't download a language file, the next step in the installation is the database configuration.
- All instructions regarding the downloading and installing of language files are now hosted at http://drupal.org/localize and not in code anymore.

Putting the link to http://drupal.org/localize on the profile selection page makes sense, because then the user can still decide which profile to use for installation. Having it on the 'Choose language' page is one step too late.

I'm not so sure it makes sense to put the link a screen earlier in the process. Technically yes, but for ux it kinda sucks. Choosing an install profile already is a non-trivial WTF for many ("what is an installation profile anyway?"). Adding another *unrelated* question in the mix there means even more thinking for the person installing. We want to minimize the amount of work people need to do to get them through installation.

I'm thinking that if the 'Learn how to install…' link is clicked, it shows a 'Did you add another language? Reload this page to choose it' bit.

something like this:

and then

@yoroy: I don't think this is practical.

If we change the link "Learn how to install Drupal in other languages" to point to http://drupal.org/localize (en external URI, that is), we have no way of changing the state of the language selection form on the "Choose language" page.

Your proposal would only work if we left the instructions for downloading a translation in code. If we did this, we could redirect the user to the "Choose language" page after he has read the instructions (and possibly downloaded a language file), but then we would already reload the page so the extra link to relaod the page is not necessary.

In effect, we would be back at the patch in #34.

Let's try to do the simplest possible solution here. I don't think we need to change the design of the installer - we can still leave a separate page, just remove the (incorrect) technical instructions from that page in favor of the drupal.org link.

I also think having "Learn how to install Drupal in other languages" pop up an outside website is a bit unexpected, and the "reload this page" link seems a little awkward, especially when the existing workflow already solves that problem...

How about something more like the attached? No workflow changes, just different text and a link to the new d.o. page. (We could also try to improve/shorten the language on that page further - I just removed what I thought was the minimum amount for starters.)

Improving the overflow workflow of the language selection screens in the installer is definitely a good idea, just probably best done in a different issue (and maybe not for Drupal 7). It's a tough chicken-and-egg problem :)

Hmm yeah, I was assuming the link to open in another window/tab. We need more ideas then. Putting the language link on the profile page is bad.

By the way, if we are looking to shorten that text more than in my patch in #60, I might just suggest replacing the entire bottom three paragraphs with this:

"Once you are finished, decide how the installation should continue:"

Basically I agree with #60, however I see two (probably minor) problems:

- The new "Choose language" page is a lot of text to read. Maybe the two links at the bottom should stand out more (styled as buttons, maybe?)
- When we ask the user to install a language file in the instructions on http://drupal.org/localize, we tell him that he has to place the file in the correct profiles-subdirectory for the installation profile he has chosen in the step before ("standard", "minimal" or whatever). At this point in the install process, he probably doesn't know anymore which profile he has chosen. Additionally, there are at the moment five profiles directories ('default', 'standard', 'minimal', 'testing' and 'expert'), of which only two ('standard' and 'minimal') are presented to the user during installation.

I think you need a fresh CVS checkout - there are actually only three directories now: 'minimal', 'standard', and 'testing'. However, your point is well taken :)

But still, I'm not sure this is any worse than before. The existing page already has a wall of text, and I believe my patch makes it shorter than it was. Plus, as described in #62 we could make it even shorter still.

Also note that currently, this page only displays to people using the Standard profile. So we could use that info to make the instructions more clear. Or alternatively, we could fix that - #562722: Language choice during installation - Drupal(minimal) profile skips language choice. It may be the case that with the new method for installing languages (no longer extracting a single tarball), some of the reasons that issue was hard to fix are no longer true anymore? Either way, we know what profile the user has chosen at this point, so we could put text on the screen reminding them if that helps make it easier.

This text is not actionable, the previous was. So we are in anyway, trying to avoid mentioning the actionable because it might become outdated - which is bad for UX, if its clear that is the direction we whish to take.

I suggest focusing on :

• For Drupal in different languages, you need a .... file
• This ... file can be found at ......
• For more information about translation see ....
• Return to choose language select to select your newly uploaded language
• OR continue with English

I think thats the primary information we want to convey.

Agreed on keeping the current workflow and link to d.o. from the instructions page in the installer. Lets rework the text following bojhans outline then.

Suggestion:

To install Drupal in a different language you need a translation file. These can be found on the <a href="">Drupal localisation site</a>.

For detailed instructions on how to install with a different language see <a href="http://drupal.org/localize">http:/www.drupal.org/localize</a>

If you added a new language: <a href="">return to the language selection screen</a><br />
Or <a href="">continue installation in English</a>

EDIT: cross-posted before reading #64-#67 :-(

Here is the patch from #60 with the links styled as buttons. Screenshot attached.

I also noticed that we show this page only when the standard profile has been chosen (condition if ($profilename == 'standard' && $install_state['interactive']) { in line 1206 in install.core.inc). As to why, I don't know.

We could now do two things:

1) Remove the condition to enable the help text to be shown for all install profiles
2) Leave the condition in - but then the help text on http://drupal.org/localize is unneccessarily complicated. It would suffice to tell users to download a translation file and put it in /profiles/standard/languages - no need to think about which profile-directory to put it in.

If we choose 2) we could then

a) either re-include the help text into the installer code since it's much simpler or
b) create two help pages (or further differentiate the help page drupal.org/localize) on drupal.org - one with instructions for setting up a translated Drupal before starting an installation, the other, simpler one with instructions for users who get there from within an installation process.

would it not be possible to try to list the translation files during the installation if at all possible, then have the note there is its not. I recognise that this probably isn't possible at this stage of D7's development, but would it not be a goal for D8?

Also in the same concept, the language should be the first option that is given if at all possible.

apologies for the semi-OT hijack,

I feel both @reglogge and @verbosity are trying to kill a few extra kittens here. Lets focus on the critical. Can someone put up a patch with yoroy's suggestions?

I do not think its right to use buttons, there is no reason to make the links at such a short page stand out even more. Buttons are reserved for actions, not for going to other pages (remember they already stepped out of the flow).

My try attached. Should look like this:

Just for argument's sake... This is basically what this page used to say, with a link to continue, but you guys bit my face off ;) and told me it had to be a form + button so that the progression along the installer wasn't jarring. This goes back to jarring again.

See #537766: install language selection should be radio buttons.

Hahaha, oops. Bojhan just informed me that this is the "help" page that you get to by navigating from the langauges page in the installer. Sorry, I was confused by the active task.

Ignore me. :D

regarding #64:

Also note that currently, this page only displays to people using the Standard profile. So we could use that info to make the instructions more clear. Or alternatively, we could fix that - #562722: Language choice during installation - Drupal(minimal) profile skips language choice. It may be the case that with the new method for installing languages (no longer extracting a single tarball), some of the reasons that issue was hard to fix are no longer true anymore? Either way, we know what profile the user has chosen at this point, so we could put text on the screen reminding them if that helps make it easier.

The new method for installing languages (with a single .po file) already makes it possible to close that issue if we remove the condition that the help-page is only shown to users who have selected the standard profile.

Running the risk of killing too many kittens with the attached patch ;-) it nevertheless does these things:

- strips out the limitation of showing the help text page only when using the standard installation profile. Installing in other languages works for the minimal profile as well.
- adds the simple instructions on how to download, rename and correctly place the translation file back into the installer. The directory for where to put the translation file is determined dynamically according to the installation profile selected before.
- eliminates the need to leave the installation process to get instructions from an external website.

I don't have a screenshot to share, but I'm sure someone creates one. Thanks, Bojhan + yoroy for teaching me all the way down in the D7 rabbit hole. :)

@Gabor Hojtsy: In #23 you say it doesn't make much sense to send people to http://localize.drupal.org to download the .po files manually. I agree with that.
My question, though, is:
If l10n_server can build .po files in the core format (translations directories) and Drush Make now supports automatically pulling those translations from l.d.o (the code would have to be adapted to fit the core format, of course), then what exactly prevents us from automatically building up localized Drupal builds for people to download. Then on http://drupal.org/project/drupal (or whereever it is people donwload Drupal) and, I guess additionally in install.php, we could simply link to a page which lets you download a fully localized Drupal build.

The last couple of patches seem to provide a good argument for leaving the instructions as part of the installer, since they allow the exact directory to be displayed to the user. But how do we reconcile that with the idea that these instructions might change later in the release cycle - I thought that was one of the reasons proposed for taking them out of the installer and having them live on d.o. only?

BTW, I forget if someone suggested this already, but I wonder if we shouldn't also just ship the core profiles with the profiles/standard/translations and profiles/minimal/translations directories already created (and a README in each)? That might help make the process a bit easier for people.

@David: The original impulse for this issue was that the instructions we had in code were simply wrong and the process of getting translation files messy. In the meantime Gábor greatly simplified the downloading of translation files with the establishment of the downloads page at http://localize.drupal.org/download. So a case could be made that instructions in code aren't that bad anymore. Actually their value should be weighed against the (IMHO) WTF of having to open an external website to get instructions as to how to proceed during an install.

As to the problem of the instructions probably changing later on: That would be problematic if the instructions were actually translated (string freeze etc.) - as it is, they are always shown in english since there is no translation incorporated at this point in the installer :-). The only edge case being that IF we had ready-made Drupal packages with other default-languages than english with which to start an installation from, then these help-texts would need to be translated. I am not aware of any such installation packages.

If we leave the instructions in code now and later on change the way in which the process works, then we of course would have to change these instructions, too. But that would then have to be a part of any such patch.

As to shipping core with the /translations directories already created: That is a very good idea IMHO.

I have attached a patch with a minor change in the wording that incorporates this idea.

The current text is far too lengthy. Use #76 as base for further patches, please.

And +1 for shipping with a /profiles/$profile/translations directory.

Note that this patch allows you test it in an already installed site. Just visit install.php.

See also the screenshot. Heavily simplified.

#81: drupal.install-language.81.patch queued for re-testing.

This is getting better and better :-)

Just two little changes:

- The directory given in the patch from #81 /profile/standard/translations/de.po is not a directory but a file. Changed it to display only the directory.
- Renamed the link to the reload-page to better match the instructions from the text above

Patch and screenshot attached.

So here's a full patch, same as #84, but additionally creating the translations/README.txt files.

INSTALL.txt has to be updated as well. It currently says

     If you would like to have the default English interface translated to a
     different language, we have good news. You can install and use Drupal in
     other languages from the start. Check whether a released package of the
     language desired is available for this Drupal version at
     http://drupal.org/project/translations and download the package. Extract
     the contents to the same directory where you extracted Drupal into. 

Can just be replaced with the same text as in the installer I think.

Good catch!

Couple of n00b questions/observations. Not sure all of them are related resolving this issue, but bringing them up.

1. In Firefox, Safari, and Chrome, at least, I don't actually get prompted to download http://ftp.drupal.org/files/translations/7.x/drupal/drupal-7.0-alpha6.af.po. It shows up in my browser. Is that something that can be dealt with on the server side at localize.drupal.org? Else, I think we'll need to expand the instructions to tell people to "File > Save as" that file.

1b. How does it deal with line breaks if that happens? Will Windows users potentially have issues File > Save Asing something?

2. We should make sure we specify "...for your version of Drupal" since there seem to be 5.x 6.x and 7.x translations on that page.

2b. Do we have any error trapping at all about people accidentally downloading the wrong translation versions? I'm not sure we can actually check for that...

4. + $output .= '

';

What is the "language selection page"? Should we put a link here, or additional explanation, or is the fact that it's got a link below sufficient?

5. "+
+ - Rename the downloaded file to your language's ISO code (e.g., de.po or
+ fr.po) and place it into the following directory:
+
+ /profiles/$profilename/translations/
"

What the heck is $profilename? We'll need to expand this more to explain what profiles are, IMO.

6. If I only download the core translation, I'm still going to end up with English all over my site when I add contrib modules. Maybe add a note about where to go to find more information about translating other aspects of Drupal.

Re webchick in #89:

1. Very true, I noticed this too. This should be split off into a separate issue on l.d.o., since we cannot patch this here. I think the PHP header() function could make it work to force the downloading of .po files.

EDIT: Created this issue: #911696: .po files are not served as downloads

2. The attached patch addresses this issue.

2b) I don't know. The .po files have a header which reads something like this:

# German translation of Drupal core (7.0-alpha6)
# Copyright (c) 2010 by the German translation team
#
msgid ""
msgstr ""
"Project-Id-Version: Drupal core (7.0-alpha6)\n"
"POT-Creation-Date: 2010-09-10 02:10+0000\n"

Maybe we could add an error handler somewhere that parses the Project-Id-Version string? Probably also something for a follow-up issue.

4. A link that is named the same is right below this line. No problem I think.

5. The attached patch adds some text here. However the paragraph in INSTALL.txt (and this issue also) deals with translating Drupal. I don't think that this is the right place to address the concept of installation profiles. Maybe open a new issue for this?

6. There are already help documents for users who have enabled the locale module. Since locale module is not installed by default, this probably shouldn't be in INSTALL.txt.

I also found some instances of links to the old translations page in locale modules help texts. The attached patch fixes these and updates some help texts too. Screenshot attached.

+++ INSTALL.txt	14 Sep 2010 20:05:14 -0000
@@ -72,12 +72,24 @@ INSTALLATION
+   - Download a translation from the translation server:
...
+     Make sure to download the translation file for your version of Drupal.

We can merge that second sentence into the first.

+++ INSTALL.txt	14 Sep 2010 20:05:14 -0000
@@ -72,12 +72,24 @@ INSTALLATION
+     installation (usually this will be the standard installation profile's
+     directory):

Can be shortened into 'usually "standard"'

+++ INSTALL.txt	14 Sep 2010 20:05:14 -0000
@@ -72,12 +72,24 @@ INSTALLATION
+     ¶

Tab or trailing white-space here.

+++ includes/install.core.inc	14 Sep 2010 20:05:15 -0000
@@ -1203,16 +1203,29 @@ function install_select_locale(&$install
+            '@profile-path' => "/profiles/$profilename/translations",

We've lost the entire patch hunks from my patch that were adding the translations/ directories to core profiles.

+++ modules/locale/locale.module	14 Sep 2010 20:05:15 -0000
+++ modules/locale/locale.module	14 Sep 2010 20:05:15 -0000
@@ -56,15 +56,15 @@ function locale_help($path, $arg) {

This entire Locale module help looks and reads like a big mess. If webchick would be OK with it, I'd prefer to defer that to a separate issue.

Powered by Dreditor.

- removed patch to locale.module
- reinstated the README files in the new translation directories. Diffing with cvs didn't catch these...
- did text changes according to #91

+++ INSTALL.txt
@@ -72,12 +72,23 @@ INSTALLATION
+   Optionally, to install Drupal in your language:
...
+   For detailed instructions, visit http://drupal.org/localize. You may also
+   install Drupal in English and install additional languages later.

Since this is not comparable to a browser UI, I wonder whether that last note shouldn't come first; i.e.,

"By default, Drupal is installed in English, and further languages may be installed later. To additionally translate the installer:"

+++ INSTALL.txt
@@ -72,12 +72,23 @@ INSTALLATION
+   - Download a translation file for the correct version of Drupal you are
+     installing from the translation server:

We can shorten
"for the correct version of Drupal you are installing"
to
"for this Drupal version"

Powered by Dreditor.

Just a quick note.

If we're changing this

-      if ($profilename == 'standard' && $install_state['interactive']) {
+      if ($install_state['interactive']) {

(which we should), then I think we also need to change the code comment above it:

    // If only the built-in (English) language is available, and we are using
    // the default profile and performing an interactive installation, inform
    // the user that the installer can be localized. Otherwise we assume the
    // user knows what he is doing.

and further down below it:

      // One language, but not the default profile or not an interactive
      // installation. Assume the user knows what he is doing.

as well as this code elsewhere in the installer (which generates the link to this page):

  if ($profilename == 'standard') {
    $form['help'] = array(
      '#markup' => '<p><a href="install.php?profile=' . $profilename . '&amp;localize=true">' . st('Learn how to install Drupal in other languages') . '</a></p>',
    );
  }

Right?

(see the old patch I had at #562722: Language choice during installation - Drupal(minimal) profile skips language choice)

Rerolled with the improvements from #93 and #94.

Anything without a screenshot is "need work".

There are no changes to the installer screens in this issue since #84. I have re-attached the screenshot from that patch.

The only other visible change is in INSTALL.txt, which I have also attached. The relevant part is in here:

INSTALLATION
------------

1. DOWNLOAD DRUPAL AND OPTIONALLY A TRANSLATION

   You can obtain the latest Drupal release from http://drupal.org/. The files
   are in .tar.gz format and can be extracted using most compression tools. On a
   typical Unix command line, use:

     wget http://drupal.org/files/projects/drupal-x.x.tar.gz
     tar -zxvf drupal-x.x.tar.gz

   This will create a new directory drupal-x.x/ containing all Drupal files
   and directories. Move the contents of that directory into a directory within
   your web server's document root or your public HTML directory:

     mv drupal-x.x/* drupal-x.x/.htaccess /var/www/html

   By default, Drupal is installed in English, and further languages may be
   installed later. To translate Drupal during installation:

   - Download a translation file for this Drupal version from the translation
     server:
     http://localize.drupal.org/download

   - Rename the downloaded file to your language's ISO code (e.g., de.po or
     fr.po) and place it into the directory /translations right below
     the installation profile's directory that you want to use for your
     installation (usually "standard").

       /profiles/standard/translations/

   - Reload the language selection page after adding translations.

   For detailed instructions, visit http://drupal.org/localize.

Ok, I hope you understand with all the code changes going on its hard to spot. I suggest the following :

• Choose a installed language
• Continue installation in English

That way we can drop requirement "3".

How about removing step 3 from the instructions and then offering these two links:

How should the installation continue?

• Return to now choose a language
• Continue installation in English

This would offer a bit more affordance, I think.

In terms of the actual user friendly plan, I've built out the l10n_install profile (currently for D6) to be a working proof of concept yesterday, so you can get a /feel/ of how it could work for the user eventually. The D6 profile includes all installer translation files so D6 shows a list of languages to choose from. That has some missing pieces in core, see #912218: Add missing languages present on localize.drupal.org which needs to be tested/committed for that. Then because installer translations are there, the installer is shown in the chosen language. Finally it adds another step/task in the installer to automatically download the .po file for the chosen language from localize.drupal.org and import in the background. So once you are finished installing, the whole of Drupal will be localized. No user interaction to put .po files into place or figure out language codes or rename files required => no docs required either. Internet connection required though.

Note that just the installer translations add 2.4MB to the overall weight of the uncompressed distro :) The idea for the D7 distro is to actually look at l.d.o's XML metafile of its supported languages from the start and show a list of languages to choose from based on that. D7 actually lets us to hook into the installer as early (unlike D6, which requires actual .po files to be there). Then we can possibly download the .po file even for the installer (for that D7 might need some tweaking still).

Ultimately, I think automated tools work much better, since once you need to add 10 modules when using 3 languages, you'll need to download 30 .po files and import them in some way. Automating finding and importing those would be a necessity then. So the idea is to automate from the start and unify it for core and contrib instead of trying to keep the old, cumbersome and manual process alive for core and suggest tools for contrib.

Once again, this will not be in Drupal core because it needed/needs significant feature development and it did not get an exception at feature freeze a year ago. It did not mature much in contrib either, as we focused on building out localize.drupal.org backend and UI-wise. However, the Drupal core instructions and guidance would ideally be ready to direct users to the easy way once it is built out properly. You can take l10n_install for a spin now to have a better idea, it has a yummy development snapshot: http://drupal.org/project/l10n_install

Hopefully this puts my arguments into more context and shows it is less hand-wavy then it maybe looked like :) The whole D6 l10n_install profile is less than 100 lines of code ATM (which is enough to make it work as a proof of concept).

@Gabor You are very confusing, cool concept but what has it to with fixing this issue? Are you suggesting we should implement your concept to fix this issue? If yes, please discuss with commiters whether this is still within the scope of Drupal 7. If no, I think we are really close to RTBC - so would be helpfull if you can do a code review.

Ok, I'll try and rephrase my second to last paragraph then: This will not be in Drupal core, and definitely not suggested as an approach for this issue. It will be at least in one distro and will be included with other distros as well. So the fix committed here would ideally take that into account or at least be open for future modifications regarding new workflows. This working distro also probably sheds some more light on why several things are done as they are on l.d.o.

Cleaner?

Yup :) Thanks

#3: choose_language.patch queued for re-testing.

Thanks for that detailed explanatation Gabor.
So instead of adding this load of help text in this issue, IMO, we should remove the whole thing, and just put a big 'ole "Download Drupal in other languages" (links to drupal.org/project/l10n_install) whereever people currently click to Download Drupal on drupal.org.
?!?!

I have been following this thread for a while and I felt it was time for also me to chime in.
+1 from me to replace the detailed language explanation in the installer with a "big image" :) and let the doc live on drupal.org since the translation server project is such a moving target and I still think the instructions a bit scary for a n00b, not that we currently can make them less scary but I also believe that we over time are able to make this easier, especially when multiple languages are needed and and we are actually able to produce the correct filename needed for selected languages. I know that I do not providing any new information to this thread but need to chime in.

Cheers
Steinmb

1) Distro/install profile talk is off topic for this issue.

2) The currently proposed, entirely revamped translation installation instructions are anything but "scary". We've made very good progress to cut them down to bare essentials that humans can quickly and easily understand. In fact, I find the instructions totally simple to understand now - it's rather http://localize.drupal.org/download that confused me most (why are all those previous versions listed there? why would I ever want to download outdated translations? there's too much stuff on that page that draws attention), but we can improve the UX of that download page separately.

No time for a review now, but will do later.

It's not off-topic at all. We are discussing how we want to make it possible for people to localize Drupal. And I simply cannot except that in the year 2010, when we have very advanced tools at our hands (l10n_server and drush make both available on the d.o infrastructure) we make users follow a 3-step-guide to be able to localize Drupal.
1. I'm not going to play status ping-pong here, but that actually qualifies as a critical regression, because in D6 I was able to download the translation in the correct format and just upload it to my server, as I would with any module or theme.
2. Actually using the described format and placing it in your profile directory is not the correct way Drupal is actually localized. This means that, among other things, all strings that exist in Drupal are being loaded, including those for modules that might never be installed. That alone also is reason enough to fix this issue in a different way than it is proposed.
3. And yes, who are you kidding: The text is scary. Not to you, not to me, but to people who just bought their first ever 2$ hosting account.
And also this discussion belongs right here in this issue, because to prevent this patch from being committed, we need a viable alternative, which is what I'm trying to get at.

I hear you :) However, both Gábor and http://drupal.org/project/l10n_install and the code in http://drupalcode.org/viewvc/drupal/contributions/profiles/l10n_install/... clearly state that this download approach does not work on some (shared) hosts, most likely due to PHP memory limitations.

Right. Which is why I'd rather work on removing that limitation, than introducing this help text. That's all I'm saying.

We're not revamping the way that translations work at this stage, sorry. Fixing instructions are all we can do at this point.

Hopefully this approach gains some real traction during the D7 release, however, and we can get it into core for D8.

Who said revamping? This is all about integration with l.d.o. Currently l.d.o provides those all-in-one .po files that you have to download, rename, etc. This issue is about inlining the currently inaccurate documentation with that process.
What I'm saying is that this process is horribly broken and we need to fix it. And it's not that hard, either, because, again, the tools for that are already in place. That doesn't have anything to do, with changing anything in core (except exactly this part of the installer text this patch is targeting). l10n_server has the capability to build up translations in the correct core format. Drush Make can build up packages with translations. All we need is to figure out how to integrate the flow from l.d.o to d.o to the people's servers. And l10n_install goes a long way already. The memory issues could be alleviated if l.d.o starts the .po files in the correct format and through Batch API. And then we can still work on e.g. dynamically fetching the installations during installation later, once we got the rest worked out.
I guess what I'm trying to convey is that with the current state of l10n_server, l10n_install, etc. we're already 98% there. And the remaining 2% will happen sooner or later. So why turn the localization of D7 into such a horrible regression and push this to D8, instead of choosing sooner rather than later?

Yes, but improving l10n_server will be an ongoing process, no? I don't understand why we don't choose to only put the generic version of the instructions (à la #71) in here and knock down this critical instead of waiting on some 2% fixing stuff with drush make batch api fetching etc. As it is, you basically have to restart the installation process anyway, detailed instructions or not.

I happen to think that the patch in #95 (probably with the further simplifications in #98 and #99) is better than #71.

- It avoids sending people to an external site to get totally simple (2 steps actually) instructions which could just as well live in code.
- It also shows these instructions to users who selected another install profile than "standard" which #71 does not do.
- It pre-creates the "translations" directories where users would place their downloaded translation files.

I'll be glad to reroll #95 whenever we agree on the wording changes from #98 and #99.

#113 / Patch #71 would be fine for now. But by committing these detailed instructions (in the later patches) to the source code we are locking ourselves into the current (if not past) way of doing things for next 2 years (at minimum).

Right, my worry is about the lock-in by too detailed instructions for a process that hasn't settled yet (and we shouldn't wait for it to settle either).

@relogge Please reroll #97 with #98 and #99 (it's more clear then #71). And get this issue fixed - as much as I love that we are changing the process, untill that is done this text is up-to-date. Lets change it whenever its appropaite, and not worry about writing into the future :)

@tstoeckler: You said in D6 I was able to download the translation in the correct format and just upload it to my server, as I would with any module or theme. That is not really true. The translation packages on http://drupal.org/project/Translations contain a deep directory structure, which if you extract to the right place should get all files fall into place. This is a confusing process on Macs where extracting to an existing directory *overwrites* that directory by default. It also causes problems based on how your extraction tool works, see #864570: Localized install is not explained properly in INSTALL.txt. Basically the process for those packages requires "manual" merging of two directory trees (or more if you need more languages). This is hardly intuitive to many users.

Whether the Drupal core translation should be one file or not is a conceptual decision we should debate elsewhere. I outlined the reasons for that above, and would not go into that more on this issue. I think what you need to see clear is that this is not a D6 to D7 change, this is a d.o => l.d.o change, and l.d.o introduces new processes which are both better for translators and users in several ways, but need some alignment in how users obtain translations. A bigger change is that Drupal contribs will not include any .po files, so for each contrib you add, you need to obtain translation files separately, just like you did for core. There are many advantages to this (eg. smaller contrib download, more up to date translations, and most importantly the possibility to translate a module *after* it is released). However, it complicates the user workflow to obtain translations quite a bit. This is not a D7 thing, its the same for all Drupal versions.

So due to the above we thought it would be ideal to provide a client tool which could help you automate this job. It is about downloading and importing files located at known URL patterns after all. Because of the process changes, D7 indeed regresses in setting up a localized site out of the box, but the tools we build at http://drupal.org/project/l10n_install and http://drupal.org/project/l10n_update (which will be shipped with http://drupal.org/project/l10n_install eventually) will be a big step forward from Drupal 6.

It was a conscious choice to decouple translations from d.o code projects, so even if we try and reproduce the old packaging format on l.d.o for core, there are new pains to go through for contrib, so we thought working on automated tools which install Drupal localized *without user effort* is best. We could build it in a way to preserve the old D6 pains for core and still have new pains for contrib, but instead we looked at eliminating the D6 and D7 pains with a distro. That D7 out of the box will be more effort to install localized is a nature of how code freeze works and how d.o does not stop changing in the year while no new features are allowed for D7. (Make no mistake, same applies for D6, which is frozen for years and becomes just as much harder to install out of the box as D7 with the changes introduced with l.d.o). Thankfully we now have tools to build distros on drupal.org, so we can build targeted distros to make localized installs easier.

FYI I've worked on a straight D7 port of http://drupal.org/project/l10n_install yesterday and submitted a working -dev release of that which should be available later today. @sun, @tstoeckler: For the memory and time limit issues in the current l10n_install concept implementation, we have work in progress at #569004: Add support for seek based batch import of .po files.

In short, this is a process change on d.o and not a D7 change, so once we have better instructions for D7, we can backport to D6 as well.

EDIT: Cross-posted again :-(

I will reroll #95 with #99 and post the new patch here.

Here is the reroll of #95 with some smoothing of the text as suggested in #98 and #99.

Screenshot of the help text page is attached.

Ok, code review please! Text is good now, if code is too lets RTBC this.

I'm wondering about the memory limit requirements of this approach. The file you put under the install profile is parsed and read into a huge array in memory in each HTTP request, setting a new "baseline" for memory use on top of which the module installs will happen. So if you put the whole distro translation there (which is about 400k-500k in size), that could end up being a huge array to manage in memory.

Ok, I made this little change in includes/install.core.inc:

-  print theme('install_page', array('content' => $output));
+  print theme('install_page', array('content' => $output)) . memory_get_usage();

This shows that my unlocalized Standard install goes from 6770880 bytes through 8315672 bytes to 16863772 bytes while it reaches the config screen. With the Hungarian translation loaded, it adds about 1MB to the installer (9470808 bytes when installing modules) and goes to 18107652 bytes for the config screen (again, around +1MB).

This is probably not too big concerning we have a minimum memory limit of 40MB in Drupal 7, so this does not look like an issue.

@Gabor How can this text patch have a performance impact?

Code review please :)

It has an effect as demonstrated, anyone can reproduce :) With the previous package format + instructions, you had a 40k-50k file under the profile, now you have a 400k-500k file, which is parsed and put into memory as an array entirely on all installation pages. As demonstrated above, it is still well within the expected 40MB memory limit on my setup at least.

The performance effect named by Gábor is not introduced by this patch at all.

Rather it was introduced by the decision to change the translation process to require one big .po file as opposed to the earlier way of having smaller .po files in all the module's subdirectories.

That happened a long time ago and discussion of this should not be part of this issue which deals with the *wrongness* of instructions we have in place.

The performance effect is introduced by this patch in a sense that a new packaging *and* import process was planned for the new format (which is under implementation in drush make and l10n_install/l10n_update). This patch tries to match the new format with an old import process for which the format was not designed (but it works with albeit the performance implications). As I've said above, I'm hopeful we can replace the built-in instructions with something like "if you need a localized Drupal install, use a different distro, not this one" when we have the distro built out for mass use + we can direct people that way on d.o as well before they actually download Drupal itself.

That is once again the "longer term" plan (maybe before 7.0 is released, maybe after). In the meantime, matching the new format with the old process works and does not have a performance effect that it would skyrocket outside of the minimum requirements as demonstrated above.

@Gábor: Thanks for the clarification :-)

The next step would be to get a code review and then finally close this special issue, right?

This is looking good, but I don't like the wording of "Return to choose a language".

I think "Return" is a confusing word to use here. *We* know that, technically, the page is reloading in order to detect the .po files, but users don't need to know that. As far as they are concerned it is just the next step in the process. I suggest something like "Choose the language you installed" or even "Choose the language you just installed".

What do they see when they click this link? Presumably the download instructions are not repeated, they just get radio buttons to select English and whatever language(s) they downloaded.

@StuartJCNCC Agreed, that is better. Lets wait for a technical review and then reroll with "Choose the language you installed" - the word just implies a certain time, that is an assumption :) and adds little value.

Ok, on technical review, there are two things popping out for me:

1. As mentioned above multiple times, these strings cannot be translated in any way because you did not yet select the language (or if you did via prefilling the URL, this page is never shown). So using st() is pointless. In fact it means this text ends up on localize.drupal.org and in .po files but then never used. So pointless work for translators.

2. You've removed the conditional on the standard profile. The reason it was there is to make life easier for the contrib distro developers. Imagine Open Atrium on Drupal 7. If the installer suggests you can download translations from l.d.o for that distro, that might or might not be right (depending on where drupal.org distro packaging stands at that point). Even if it is right, they need to consciously look for the Open Atrium project on l.d.o, not the main Drupal project to have a proper / complete .po file. (But currently they need to look at translate.openatrium.com anyway). So it was consciously skipped to help contrib profile developers, to avoid misleading their users. Now this is a D6 remnant, and there was no possibility to alter the install tasks in D6, just to add to them, so core tried to be out of the way to not add these if you probably don't want them. Now in D7 contrib distros can just alter the install_select_locale step and the two locale import steps out (as l10n_install for D7 does now), and do whatever they want in place. So its not required anymore. In short: this change is fine.

@Gábor:

1. As mentioned above multiple times, these strings cannot be translated in any way because you did not yet select the language (or if you did via prefilling the URL, this page is never shown). So using st() is pointless. In fact it means this text ends up on localize.drupal.org and in .po files but then never used. So pointless work for translators.

There is one rather obscure edge case, where these instructions might show up in translated form: It could occur when the owner of a previously translated website choses to run the installer again. I have no idea who would ever want to do this, but technically it is at least possible.

Weighing this against your point about creating pointless work for translators, I would be comfortable with removing st() from the patch. The less work for translators, the better.

Are there any objections to this?

If someone who installed Drupal previously runs install.php again, they get a nice screen that Drupal is already installed, and they will not be allowed to go into language selection again. Even if they are allowed to go to language selection, once again, if the installer somehow knows about the language they use, this screen will not show, if it does not know, we don't know how to translate the screen.

You are of course right... (bows)

Here is a reroll with translations removed and the wording change from #129, #130

re #129: We should keep and use the word "Reload", so that users who manually download translations, and who go back to the language selection screen BEFORE putting the translations in place, realize that they have to reload the page to make them visible.

re #131: So wouldn't it make sense to add a .info file property for install profiles and only show download instructions if it is set? e.g.,

locale-translation-url = http://localize.drupal.org/download

So Open Atrium can happily link to its own distro translation server, and there can be install profiles that skip the translation download instructions entirely.

I guess what sun says about Reloading makes sense.

Ok, I renamed the link to "Reload to choose the language you installed".

Another bugfix/change:
When the user returned to the language selection page after downloading another language file, the link "Learn how to install Drupal in other languages" was still visible but didn't lead anywhere because the help page is shown only when there is no additional language file present.

I now added an if-statement that shows the link "Learn how to install Drupal in other languages" only if there is no additional language file already present.

This seems logical since we allow for only one language to be selected as the new default language during installation anyway - right?

Looks good to me.

I like sun's suggestion in #135 about adding a "locale-translation-url" property to .info, but that can be discussed and implemented in another issue.

Since this was already reviewed by sun, Gabor and others, and all raised issues have been fixed, setting to RTBC.

I will only once more advise to go back to patch #71, in order to have the Drupal core source code independent of technological improvements in the d.o infrastructure. As I have stated above numerous times, committing this patch will lock us into deprecated technology/functionality for the next 2-3 years. If that is what you want, proceed. I can only state the obvious, not prevent it.

#71 Was not actionable enough as discussed in the last 40 comments (I clearly do not see the argument of going for text that is bad in terms of usability for the sake of future-proofing). Since this is not translated by anyone, I see no reason this couldn't be updated in any release in the next 2-3 years, if it does change.

Yes, this can and hopefully will be modified later.

Allright, I'm convinced this is the right trade-off to make. Lets fix this for how it works *now* and revisit if/when the situation has changed.

+++ INSTALL.txt
@@ -72,12 +72,23 @@ INSTALLATION
+   installed later. To translate Drupal during installation:

+++ includes/install.core.inc
@@ -1198,21 +1198,28 @@ function install_select_locale(&$install_state) {
+          $output = '<p>Follow these steps to translate Drupal into your language:</p>';

I think this should be

"To already translate the Drupal installer:"

Or perhaps we want to take over the initial sentence from the instructions screen?

Anyway, that current sentence in the README.txt is not really clear and sounds like there'd be an interface that would allow me to manually "translate Drupal during installation", i.e., I'm associating a translation interface...

+++ INSTALL.txt
@@ -72,12 +72,23 @@ INSTALLATION
+   - Rename the downloaded file to your language's ISO code (e.g., de.po or
+     fr.po) and place it into the directory /translations right below
+     the installation profile's directory that you want to use for your
+     installation (usually "standard").
+
+       /profiles/standard/translations/

The sentence should end in a colon.

+++ INSTALL.txt
@@ -72,12 +72,23 @@ INSTALLATION
+   - Reload the language selection page after adding translations.

+++ includes/install.core.inc
@@ -1198,21 +1198,28 @@ function install_select_locale(&$install_state) {
+          $output .= '<li><a href="install.php?profile=' . $profilename . '">Reload to choose the language you installed</a></li>';

The wording in README.txt sounds much better to me.

Powered by Dreditor.

Reroll with:

- the new link text "Reload the language selection page after adding translations" on the help text page (screenshot attached)
- "Follow these steps to translate Drupal into your language during installation:" as the new text in INSTALL.txt
- the colon

INSTALL.txt now reads:

   By default, Drupal is installed in English, and further languages may be
   installed later. Follow these steps to translate Drupal into your language
   during installation:

   - Download a translation file for this Drupal version from the translation
     server:
     http://localize.drupal.org/download


   - Rename the downloaded file to your language's ISO code (e.g., de.po or
     fr.po) and place it into the directory /translations right below
     the installation profile's directory that you want to use for your
     installation (usually "standard"):

       /profiles/standard/translations/

   - Reload the language selection page after adding translations.

   For detailed instructions, visit http://drupal.org/localize.

Back to RTBC then.

Looks great to me now except for two things:

1. +          $output .= '<li>Rename the downloaded file to your language\'s <a href="http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Officially_assigned_code_elements" target="_blank">ISO code</a>...
   

   First, ideally I don't think we should link to an encyclopedia here (a primary source would be better, for example a page on iso.org?).

   Second, the text talks about language codes but the linked-to page talks about country codes and I am not sure those are the same thing? Actually, if you look at the languages available at http://localize.drupal.org/ right now they have some like "Portuguese, Brazil" (pt-br) and "Portuguese, Portugal" (pt-pt) which don't quite correspond to either.

   We should clarify what the correct link and instructions are here. In most cases it looks to me like for the purposes of your Drupal site you just strip off the beginning of the filename and use whatever is at the end anyway?

2. +          $output .= '<p>For detailed instructions, visit the <a href="http://drupal.org/localize" target="_blank">drupal.org handbook page</a>.</p>';
   

   Possibly to make everyone on this thread happy, we could change this text to something like this:

   "For more information on installing Drupal in different languages, visit the drupal.org handbook page."

   Thereby hinting at the fact that the handbook page might also describe entirely different installations methods (like the l10n_install install profile, etc) rather than just rehashing the instructions that are here.

@David_Rothstein: On the first thing, the Drupal admin UI has this text/link, which should technically be correct:

     t('<a href="@rfc4646">RFC 4646</a> compliant language identifier. Language codes typically use a country code, and optionally, a script or regional variant name. <em>Examples: "en", "en-US" and "zh-Hant".</em>', array('@rfc4646' => 'http://www.ietf.org/rfc/rfc4646.txt'))

Can someone please patch this? Its a critical thats like 5 minutes away from RTBC

New patch with suggestions from David in #146:

1.) For the link, I now used aschiwi's suggestion, since this page gives the best listing of language codes I could find. At ISO's website there are no listings but only the possibility to buy one for a gazillion dollars. Regarding language-codes like pt-br or gsw-berne, I think hat users in these communities are quite familiar with their *exotic* language codes. Additionally, we still link to the Drupal.org handbook page, where we can easily go into all these edge cases. In a nutshell: I would leave the instructions as they are since they will cover 95% of all users and we give hints as to where to go if things fail.

2.) Adjusted the text.

Thanks!

Awesome work! All of my previous feedback looks like it's been addressed. Committed to HEAD.

Looks like this should be marked for D6 backport, since the instructions are wrong there, as well?

ISO 639 codes (which are the legacy codes used by the web) are just a small portion of RFC 4646 codes (which are the current codes used by the web). Now the installer says you should use the legacy codes, while Drupal UI says you should use the modern codes. Not good. Looks like my copy-pasting of how this is documented on the Drupal UI was ignored. I agree the linked RFC 4646 txt is not at all nice and user friendly, and lacks a list of typical language codes, but for example using ISO 639 you'd end up understanding Chinese should use "zh", which Drupal *would not understand*. Also I'd not call Chinese a minority language.

What about finding a better page with RFC 4646 compliant code examples instead of misleading people? Localize.drupal.org front page has a language code list with the human readable language names. Also, the files people download will have the language code in them (eg. drupal-7.0-alpha7.zh-hant.po and drupal-7.0-alpha7.zh-hans.po), so renaming the file based on codes looked up from a different list instead of just keeping the last portion of the filename sounds more pain). BTW every other place, Drupal understands filenames with arbitrary prefixes, it just looks at the last ".*.po" section, and grabs the * part as language code. It is probably not hard to modify core to have this either, which would simplify the instructions a great deal.

Just put up a patch to the right url, please.

Ok, looked at the code for the language code identification and it would indeed need some rework for working with arbitrary filename prefixes. I'm not sure its a huge task, but here is a quick stop-gap to simplify the instructions and make them actually correct. Localize.drupal.org should know the right language codes, no need to tell people to read other docs and rename files in wrong ways.

The patch changes the following text: Rename the downloaded file to your language's ISO code (e.g., de.po or fr.po)

To: Rename the downloaded file retaining only the language code at the end of the file name. For example, if the file name is drupal-7.0.pt-br.po, rename it to pt-br.po.

Alrighty

@Gábor: I googled far and wide to find a perfect page with the exact versions of language codes we use, but to no avail :-(

I didn't ignore the RFC 4646 text you suggested, but I think it is just about the worst text there could be. It's 59 pages of technical gibberish (pardon my english) with just a few examples of correct language codes hidden somewhere on page 55. Sorry for not pointing that out earlier. IMHO the reference to this document should be purged from from Drupal core altogether.

Two alternative suggestions come to mind:

1. Instruct the user to delete the Drupal version part of the filename before the language code part. As an example, delete the "drupal-7.0-alpha7" from "drupal-7.0-alpha7.zh-hant.po" so that only "zh-hant.po" remains of the filename. This would call for some nice wording but would have the added advantage of always working with the downloaded file since we construct the filenames in a way that they work (tested with chinese and german).

2. Amend the existing Drupal handbook page (http://drupal.org/localize) that we link to in the help text to further explain the exact naming conventions we use for translation files. After all, we already tell users that more information is to be found there.

The attached patch removes the link to an external site explaining about ISO-Codes (since there is no satisfactory one) and adds some instructions as to how to rename the downloaded translation file correctly.

sorry, cross-post...

Gábors patch is much briefer.

I am going to demote this to priority "Major", why? Because people don't have incorrect information anymore, its just very misleading :D - even then, its not a bulk of text and directs people to the handbook for more information. So as we sort out the perfect text to go along with the link, I am going to put this down to "major".

Back to Gábor's text in #155, which is really much better. Two small changes though:

- Puts filenames in code-tags.
- Adds some text to prevent filenames from line-breaking on hyphens.
- Adjusts Seven theme's IE-stylesheet to show code, kbd and pre tags in the correct size also for IE.

This page now reads and looks good in IE, Firefox, Safari etc.

+++ themes/seven/ie.css	22 Sep 2010 10:20:08 -0000
@@ -10,3 +10,10 @@ fieldset .fieldset-legend {
+/* IE renders monospace font too big */
+code,
+pre,
+kbd {
+  font-size: 1em;
+}

Can we move this to a separate issue? Meanwhile, I realized that the PRE styles we added earlier should have gone into system.theme.css instead - same as these here.

So let's create a separate issue (markup component) for those styles, so we can properly test and ensure the output of CODE, PRE, and KBD in all themes + link to that issue here.

+++ includes/install.core.inc	22 Sep 2010 10:20:08 -0000
@@ -1209,7 +1209,8 @@ function install_select_locale(&$install
+          $output .= '<li>Rename the downloaded file retaining only the language code at the end of the file name and its extension. For example, if the file name is &lt;code>drupal-7.0.pt-br.po&lt;/code>, rename it to &lt;code>pt-br.po&lt;/code>.</li>';

I think we should use "more simple" language here. Also, whenever we output file names that need to be renamed or copied, novice users really have a hard time to see the actual difference in file paths or file names, if the original and target are squeezed into a single sentence that might even wrap at an odd location.

"Rename the downloaded file to only keep the language code and the file extension. For example, if the file name is
<pre>
drupal-7.0.pt-br.po
</pre>
rename it to
<pre>
pt-br.po
</pre>"

Powered by Dreditor.

The attached patch:

- moves the <pre> styling from themes/seven/style.css to modules/system/system.theme.css
- changes the text to sun's suggestion from #161 (screenshot attached)

I have also opened this issue for the IE bug mentioned in #160: #919718: <pre>, <kbd> and <code> tags are rendered too big by IE in Seven theme.

EDIT: The <pre> styling has to go into Seven theme's ie.css because Seven theme's style.css is loaded as the last stylesheet in IE before the conditional stylesheets and we have the larger font-size in style.css for all *normal* browsers. Sigh.

'Reload the language selection page after adding translations' is painful to read, but 160+ comments on an issue like this too, so back to RTBC.
Thanks all for hanging in there, it's about time we let it go :-)

We need sign-off from someone in the markup team if we're going to add more presentational CSS to system.*.css

tagging

Yippee, I just did a successful zh-hans install with HEAD (#152). Marked #908456: Installing in chinese fails at step 3: Verify requirements fixed.

Since #919718: <pre>, <kbd> and <code> tags are rendered too big by IE in Seven theme went in, I applied the install.core.inc hunk only, and committed to HEAD. Thanks! If there's something else that needs to get fixed re: IE and pre/kbd markup, please re-open that other issue.

Back to 6.x for back-porting.

And in D6, I believe this is critical.

Has this issue been fixed in the latest D6?

No, has not been committed to D6, nor has a patch been provided.

OK, that is fine. Just checking.

The INSTALL.txt file of Drupal 6 needs to be updated to tell that the po-files should go in 'profiles/default/translations', or whatever the name of the profile.

I just updated Quick install for developers (command line) to reflect this information.

Regarding future development, I agree with attiks in #14 that it would make more sense being able to place the translation files in a separate folder outside the folder of a particular profile to avoid duplication of translation files (if you have several profiles). But that's a minor one...

Sorry, I was a little too fast firing my previous comment. It seems at the moment it is not possible at all to install Drupal 6 in another language than English using the files from http://localize.drupal.org/. If for example I try to install in Danish (putting the po-file in "profiles/default/translations"), on the install form I get "drupal-6.22.da" which I am able to select, but Drupal is not installed in Danish, and later on "admin/settings/language" I see "drupal-622da" but it is not enabled and not terms translated.

Well, I guess most users will manage to get around this and install the desired language manually after installation, but it certainly is confusing when installation instructions and help pages are misleading.

Yes, the Drupal 7 instructions used to tell you to update your .po file name to just da.po for that case before running the installer (see screenshot above: http://drupal.org/files/issues/882164-162.png). Same can be said for Drupal 6 (in the meantime Drupal 7 was updated to take more complex filenames as well). This is the reason this issue is marked to be ported to Drupal 6.

Thanks, Gábor. From what I can see, lots of stuff needs to be done to make this work in Drupal 6. Simply renaming the translation file is not enough because no strings are imported from the file. So maybe we should just change the text on the "Choose language" page and tell people to use one of these methods:

1. Use the Localized Drupal Distribution, or
2. Install in English, then after install, enable locale, install and enable l10n_update and l10n_client; add the desired language, and make that the default (and optionally change language prefixes).

What matters to me is that the instructions (both in INSTALL.txt, on the "Choose language" page, and on http://drupal.org/node/21145) are correct. We should not be telling people to do things that don't work.
So unless there are other plans for the near future, I propose we just change these instructions to reflect reality. I can help with that (I noticed also #864570: Localized install is not explained properly in INSTALL.txt).

It's been a long time... Worth just closing this, unless someone wants to push it into Core.