We had a long discussion in IRC just now about how to get installer translation files properly packaged with install profile releases. #644564: .po files cannot be committed to Drupal install profiles is definitely the wrong way to go about that. ;) Instead, we want to be able to put stuff in the profile's .make file to pull the installer translations directly from l.d.o.
Open problems:
A) There aren't really official releases of these on l.d.o yet, they're more like -dev snapshots of best-effort strings at any given time.
B) We'd need support on l.d.o to find the right tarball name given a language code and a version of core.
C) We might want a mechanism to say "give me the .po files for all languages you know about", which will also need support from l.d.o.
So, this issue might belong in the l.d.o infra queue (or least become blocked on issues in that queue), but let's start simple with a single issue here for now.
Comment | File | Size | Author |
---|---|---|---|
#37 | drush_make-644916-37-documentation.patch | 1.49 KB | helmo |
#20 | 644916_translations_v3.patch | 7.35 KB | yhahn |
#19 | 644916_translations_v2.patch | 6.89 KB | yhahn |
#18 | 644916_translations.patch | 6.9 KB | yhahn |
Comments
Comment #1
dww.
Comment #2
Gábor HojtsyOn A) core translations will probably have translations releases, but that is not going to happen soon. Until then, we need to package these on a best effort basis, pulling the translation at the time of packaging IMHO.
On B), there will be no "tarball", for a defined core version per language, since we are talking about one .po file per language per Drupal version, so we do not package that further. It's just a .po file. We can make up a file naming scheme for that on l.d.o. The translations are hosted at http://ftp.drupal.org/files/translations/ at the moment in a sensible directory structure. Only core files are produced at the moment.
For C), we have a languages.xml file in the root of the translations files (link in the point above), and that lists all languages available. Then the packaging script can traverse the file structure looking for the known filenames as we define for B) and look whether any of those are there. Package what's available.
Comment #3
kika CreditAttribution: kika commentedWhat needs to happen to make this feature a reality?
Comment #4
hunmonk CreditAttribution: hunmonk commentedD) in the drush make workflow, core translations would normally go in a distribution build .make file, not a profile .make file, since they need to be installed relative to the drupal root, not the profile root.
however, the drupal.org packaging system fully controls the distribution build .make file for drupal core. therefore we'd need another customization in drupal-org.make files as opposed to standard .make files -- namely, that they would include a 'translations' array that the packaging system would look for, and use to insert the necessary translations into the distribution build .make file that it constructs.
with that approach, we'd also need to make an adjustment to drush_make_d_o.drush.inc and drush_make_d_o.convert.inc to add support for handling the new translations array element in drupal-org.make -- otherwise the .make file would fail to verify/build.
Comment #5
moshe weitzman CreditAttribution: moshe weitzman commentedI'm working on getting drush dl command to support packaged install profiles (please can we call them distributions soon). We really want to get localization working under plain old `drush dl` and `drush enable` as well. Subscribe.
Comment #6
kika CreditAttribution: kika commented*bump* any update on this?
Comment #7
dmitrig01 CreditAttribution: dmitrig01 commentedA) That's ok, we can accept that (we can't do better).
B) Out of the scope of this issue (obviously), but still needs to be solved.
C) is unnecesarry.
kika: basically we'd probably just need some code which parses translations[] = foo
Comment #8
kika CreditAttribution: kika commented*nudge*
Comment #9
dmitrig01 CreditAttribution: dmitrig01 commentedNot really sure what to say - the next step is basically just to do it.
Comment #10
HnLn CreditAttribution: HnLn commentedsubscribe
Comment #11
e0ipsosubscribe
Comment #13
kika CreditAttribution: kika commentedSorry for hijacking the topic -- I do not know where this discussion belongs.
I feel this issue is dependent on high-level decisions on future of the Drupal translation packaging. l.d.o is great effort for getting community together, but we need to decide the packaging method and format.
There seems to be two main ways to go:
OPTION 1. Rely on our VCS (CVS, soon Git) and allow doing (semi)automatic language commits based on l.d.o database/files. Something like a button [publish a release] in l.d.o what language admins can use when they feel doing it.
This launches a script in the background what commits language files to standard translations VCS repo. For contrib modules it's trickier: should the script package as patch in the issue queue of respective module?
Non-automated version of the same flow is going on right now.
Pros:
- drush / make already support language projects downloads (although it's buggy #639158: Download translations extracts just a single file) and does not need reengineering. drush make for d.o just needs to accept
project[fr] = 1.2
. This way installer profile can import all required core .po files, including profile/*profilename* ones.- all language-packing scripts what convert .po flat package format to .po directory format will stay the same
- Old-school manual VCS commits can still be used
Cons
- Can automatic commits be done from the security perspective? Also consider upcoming Git migration.
- Does not really solve two critical translation distribution problems:
-- asymmetry between contents of VCS (flat .po) and final packaging (directory .po) format (there seems no way to get your translations from (other) repo via drush make CVS/SVN/Git backend?)
-- Core and contrib translation/distributing workflows are really different.
OPTION 2. Keep translations off the VCS, modify drush / make tools to get the translations from elsewhere, with non-standard package signatures and version handling.
Pros:
- Lot of new opportunities to simplify our messy translation distributions:
-- simpler-to-grasp and symmetrical packaging format (flat .po files with version, project and language info in filename OR .info files for translations?)
-- re-think core vs contrib translation packaging flows
Cons
- Time and resources and backward compatibility (this does not feel being in D7 core timeframe at all).
I'd go for Option 1 for now but keep discussing about translation packaging future.
Comment #14
pimok3000 CreditAttribution: pimok3000 commentedsubscribe
Comment #15
pcambrasuscribe
Comment #16
FreddieK CreditAttribution: FreddieK commentedsubscribe
Comment #17
asak CreditAttribution: asak commentedsubscribe
Comment #18
yhahn CreditAttribution: yhahn commentedHere is an initial patch modeled after the work in l10n_update and using localize.drupal.org as a default l10n server for downloading translations.
Translations can be downloaded for any given makefile using the
--translations=ar,es
flag (where a comma-separated list of languages is provided). Any project (core, profile, theme, module) with sufficient metadata (core version, project name, version) can have its translations downloaded and placed in itstranslations/
directory.Projects can make use of either the
l10n_path
orl10n_url
keys in a makefile to specify an alternate localization server if they choose to (see l10n_update for more information on what these keys should be). By default,localize.drupal.org
is used.README.txt
updated and atranslations.make
test makefile and test md5 hash entry have been added.Comment #19
yhahn CreditAttribution: yhahn commentedBad copy & paste in README. Rerolled patch with fix.
Comment #20
yhahn CreditAttribution: yhahn commentedBetter failure and smarter logic for when to not check for translations.
Comment #21
dmitrig01 CreditAttribution: dmitrig01 commentedyou are awesome
Comment #22
dmitrig01 CreditAttribution: dmitrig01 commentedwhy _url and not _server?
Comment #23
dmitrig01 CreditAttribution: dmitrig01 commentedw00t
Comment #25
osopolarThis seams to import the translations into drupal-root/translations and is not available during the install precess, or am I missing something?
Comment #26
yhahn CreditAttribution: yhahn commentedCorrect, as I stated above the translations are downloaded into the
translations<code> of each project. For a module, this would be for example <code>sites/all/modules/token/translations
and for drupal core this is justtranslations
.This may be an issue as the installer will only offer language options if there are translations in
profile/[profile]/translations
... I will look into whether downloading translations to bothtranslations
andprofile/default/translations
will work for Drupal core.Comment #27
hass CreditAttribution: hass commentedCore translation file need to be placed in core module folders, too!?
Comment #28
yhahn CreditAttribution: yhahn commentedI've committed a workaround for this issue here:
http://drupal.org/cvs?commit=416508
To summarize the challenges:
.po
file. (For what it's worth, I think this is a good thing).profiles/[x]/translations
. What's worse, the translation file must be namedfr.po
, notdrupal-6.19.fr.po
(the latter is an acceptable format for all other project translation files).profiles/[x]/translations
file is imported very early on and affects strings during the install process, while strings in, say,modules/system/translations
only take effect after installation is finished.The current workaround is this:
Create two copies of the
.po
file for the core project, e.g.:This second copy allows other l10n_update or another install profile to properly import Drupal core strings.
The main problem with this approach is
profiles/default/translations
would ideally contain only the strings needed to get through the install, not a full copy of all strings from Drupal core.I think the proper solution for this is to have the Drupal installer make an exception for the core project and look for core translations at
translations
at the Drupal root.Looking for feedback on this one.
Comment #29
hass CreditAttribution: hass commentedNo, this is a very BAD idea. You missed a few more important things.
The only reason why you lay a monster file in a drupal system module folder having all translatable strings is only that there is no button for re-importing all files and if you do not have this button you need to select every single modules file .po by hand. This is bad and I complained in many places, too, but this is part of l10n_client (however i wish this would be in core). Overall - this is no reason to make one big file if this will cause major import failures to many many people.
Comment #30
hass CreditAttribution: hass commentedCan someone explain why the splitted download is no longer available on l.d.o? In past it was... but now the selection form is no more accessible as in past.
Comment #31
yhahn CreditAttribution: yhahn commentedI agree with your points about performance and problems with expensive import processes.
If I understand correctly localize.drupal.org is meant to mirror Drupal.org projects and releases, and since Drupal core is a single project this is why the translations for the project have been consolidated into a single translation project as well. Whether it will be possible to package these translations into distinct module
.po
files is a question for Gabor and Jose I believe.Let's see if we can get them to look into this issue and give us some direction here.
Comment #32
reglogge CreditAttribution: reglogge commented#30: Split downloads are still available at http://localize.drupal.org/translate/languages/[langcode]/export
You need to be a member of the respective translation team though - anonymous access doesn't seem to exist anymore.
Comment #33
dmitrig01 CreditAttribution: dmitrig01 commentedComment #34
stixes CreditAttribution: stixes commentedsubscribing
Comment #35
helmo CreditAttribution: helmo commentedsubscribing
Nice to see the --translations=.. working already in drush_make 6.x-2.0-beta9.
Any progress on getting support for "translations[] = nl" included?
Comment #36
dmitrig01 CreditAttribution: dmitrig01 commentedprojects[] = nl
Comment #37
helmo CreditAttribution: helmo commenteddmitrig01: Thanks, seems very logical :)
But maybe it should be more explicit in the documentation, what about this patch.
Comment #38
j0nathan CreditAttribution: j0nathan commentedSubscribing.
Comment #39
eloivaqueSubscribe
Comment #40
dmitrig01 CreditAttribution: dmitrig01 commentedI'm going to make this issue as fixed for now, and if there is an issue standing (hass?), then another can be opened.