Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.As part of #ldodomination, add support for downloading the XML file generated in #568984: Define language list export format, set it up on ldo and show the available languages based on that. It should be possible that there is no internet connection or someone wants to skip remote downoloads (for build management or deployment purposes for example), so all the local file support should be intact. Support for grabbing the language list from remote would be a new thing.
| Comment | File | Size | Author |
|---|---|---|---|
| #27 | 568986-27.patch | 1.3 KB | good_man |
| #11 | install.568986_2.patch | 9.9 KB | Sutharsan |
| #10 | l10n_export_languages.zip | 1.35 KB | Sutharsan |
| #6 | install.568986_1.patch | 3.34 KB | Sutharsan |
| #4 | install.568986.patch | 4.11 KB | Sutharsan |
Comments
Comment #1
pp CreditAttribution: pp commentedComment #2
Sutharsan CreditAttribution: Sutharsan commentedPreliminary specification
Check for XML at l.d.o
fail: check for local po-file
success:
Compose a list of available languages in po-files
Display selection form for installation language
languages: english + languages found
> 5 languages: select list
<= 5 langs: checkboxes
first po-language is the default
fail:
Display form (existing installer step 2): Install in English, Learn how to install ... other languages)
success:
get XML
fail: error message
store temp file
fail: error message
read temp file
fail: error message
language selection (see: load po success)
install profile .info file may contain a setting to override the l10n-server path
install profile may contain po files for one or more languages
Comment #3
seutje CreditAttribution: seutje commentedsubscribing
Comment #4
Sutharsan CreditAttribution: Sutharsan commentedAttached patch is a partial solution. Still work in progress and for review only.
Comment #6
Sutharsan CreditAttribution: Sutharsan commentedComment #7
Gábor Hojtsy@Sutharsan worked much more on this, and will post an updated patch later. Just in the interest of keeping others updated :)
Comment #8
Jose Reyero CreditAttribution: Jose Reyero commentedThis is looking good.
About the first step, fetching language list from server, we should add some exception handling and results checking there so in case the server is down, there's no network connection, or anything went wrong during the request it fails gracefully, moving on to the next step (English, Other languages) but with a 'Retry' option...
Comment #9
pp CreditAttribution: pp commentedI had a dream. :) We should store the install profile's translation in the $_SESSION array. Is it a good idea?
pp
Comment #10
Sutharsan CreditAttribution: Sutharsan commented@Gábor Hojtsy: I worked on it too and did not your message. I traveled off-line ;) I attach a patch which now also includes storing of the localization file in the system temp directory, and handles exceptions like service is not available or temp file can not be written.
TODO: rewrite the instructions of how to install Drupal in other languages.
@pp: We considered this too but _locale_import_read_po(), used in st(), uses a file. Using a string instead requires a rewrite of this function too.
To test the code you need to add a line to the install profile .info file to override the default server path. Example:
With this path the code expects the following files:
http://localhost/l10n_server/languages.xml(file generated by code in #568984: Define language list export format, set it up on ldo)http://localhost/l10n_server//path_to_po_files/drupal_version/install.nl.po(nl = example language code, as selected in step 2)Comment #11
Sutharsan CreditAttribution: Sutharsan commentedoops, wrong attachment.
Comment #12
moshe weitzman CreditAttribution: moshe weitzman commentedHuge usability improvement.
The localization server should not use a define to drupal.org. Other profiles might want to do this differently. Please use variable_get() or some other pluggable solution that defaults to ldo.
Comment #13
Gábor Hojtsy@Moshe: the idea is that the install profile could define the server in the .info file, which would then be carried on as a default. The module needs to have a define for cases, when neither the install profile, neither individual projects (modules, themes) define this, so we need a fallback. If you look at the patch, it overrides the define from the .info file at the start and as soon as it can save variables permanently (DB is set up), it also saves it as a variable in the DB.
Comment #14
Sutharsan CreditAttribution: Sutharsan commentedThe patch has an option to add a variable to the profile's .info file to define an alternative translation service.
Is this what you mean?
Comment #15
Jose Reyero CreditAttribution: Jose Reyero commentedAbout the server, I think if the profile doesn't specify a server, we should go without one, so no default server. We don't want to push the full language list on any profile you are using, specially before this one gets in: #559294: Allow more control for install profiles: override full task list
@Gabor, could you set up some static files somewhere in the server so we can move on and test (languages.xml, a pair profiles po)?
One open question is what happens when the list from the server is not consistent when our predefined language list.
Also, we should be building some locale_remote api not in install libraries but in locale.inc so they can be reused later. This should be part of #568986: Dynamically update standard language list from localization server (I think I will be working on that one)
Comment #17
Gábor HojtsyOk, since we are not getting this into Drupal 7 due to time constraints, we should regroup to get this in as contrib functionality. This means that this issue might need to be broken down to two things. One is installation time support, where we'd ideally deliver a "component" people could put in their install profiles, so that this functionality can live on in multiple install profiles easily. Most of the functionality though should live in a module, for which l10n_client seems to be the most logical candidate. I'd imagine it growing into a module suite instead of one monolithic module.
Comment #18
seutje CreditAttribution: seutje commentedyea it makes sense that $name_client is the module that connects with $name_server :P
but I guess this would (eventually) require it to be broken up into submodules, or not?
Comment #19
Gábor HojtsyMoving to newly added l10n_update.
Comment #20
Jose Reyero CreditAttribution: Jose Reyero commentedRelated, #644916: Add drush make command for pulling core installer translations from l.d.o
(This may be the preferred solution for Drupal 6 language list because the installer makes it really difficult to dinamically change the language list if there's no po file)
So I think on this module we just add some basic API to fetch the language list, that may or may not be used by the installer.
Btw, the server language list is now here, http://localize.drupal.org/l10n_server.xml
Comment #21
Gábor HojtsyComment #22
hass CreditAttribution: hass commented+
Comment #23
Freso CreditAttribution: Freso commentedDoes anyone have a patch, in whatever state, for the current specification? Gábor? Sutharsan?
Perhaps one could start a sandbox project, where we could work on it together? (Instead of sending patches back-and-forth - this seems like the kind of issue that would benefit a lot from that kind of workflow. :))
Comment #24
Gábor HojtsyTagging for D8MI and usability for inclusion in core in Drupal 8. Moving to 7.x for l10n_update module.
Comment #25
podaroksubscribe
Comment #26
Gábor HojtsyRelated: #1295696: Sync predefined list of languages with localize.drupal.org and extend native language information.
Comment #27
good_man CreditAttribution: good_man commentedWe can get a very simplified code (thanks to the great work by l10n_update team) like this.
Comment #28
Gábor HojtsyMoving to core queue for Drupal 8. The localization update module in itself has not much use for this functionality as far as I see, but Drupal 8 does need this. Unfortunately I think this is going to be a bit farther off, since
(a) we do have a standard language list in standard.inc now
(b) this issue would be about being able to "update that" from localize.drupal.org (so the installer and admin UI uses the most up to date language list)
BUT we are not going to write PHP files in the includes dir. We could make up our own format and storage for this, but the config initiative is about to introduce a standard format/API for this and IMHO we should use that. So I think this is basically postponed on that overall.
In the meantime we can work through what kind of information we need to expose for this list on the localization server (eg directionality is not yet exposed, see http://localize.drupal.org/l10n_server.xml). We also might want to expose the overall percentage of the "featured project" (Drupal core on localize.drupal.org) for each language to display as a guide on the installer (might not end up being used but the data will be useful to potentially hide some languages, see #1337628: Enhance language select form with textbox and other tools). So I think we should work on the underlying plumbing in related issues while the config initiative gets to to a point to provide us with a storage layer for these languages, when
(1) we'll migrate the standard.inc language list to that
(2) can update it from localize.drupal.org, since we'll have all the data needed exposed there
Makes sense?
Comment #29
Gábor HojtsyOpened #1344540: Extend language list to include direction and percentage of featured project for the localization server to add more needed information to the language list.
Comment #30
Gábor HojtsyTagging for base language system.
Comment #31
clemens.tolboomJust a side note: while working on #1189184: OOP & PSR-0-ify gettext .po file parsing and generation I was tempted to allow _all_ available languages to try download the install-langcode.po when selected as the POFileReader accepts an URI to download.
(POFileWriter could write it to public://translations/ and POMemoryWriter facilitates the installer to read it)
Comment #32
Gábor HojtsyFound no support in #1632236: Convert built-in language list to CMI to move the language list out of a static PHP array dump, so this is unlikely to happen. We have bigger fish to fry to finish the .po file import system anyway.
Comment #33
PanchoI don't know. I think that it's still a valid issue that might be more easy to solve at a later point, maybe in D9. So I'm reopening and postponing this.
Comment #34
mgiffordCould it come in 8.1? Or should we just bump this issue to D9 and set the status to Active?
Comment #35
mgifford