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.After grabbing the language list (#568986: Dynamically update standard language list from localization server), we should have a good knowledge of the paths used to export translations (#568994: Implement translation package export in l10n_packager), so we can just look at the right paths (named after module versions and languages we need to download) and be able to download the latest translations.
Again, the local environment should be respected. If there are translation files set up, we should use them and the remote service should be skippable.
Also, the remote server used to pull the packages should be optionally defined per project. Just like with update status, in the .info file. That allows people to share community modules with in-house (or non drupal.org) modules where the translation updates come from elsewhere.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | 568996_update_project_locales.patch | 19.25 KB | Jose Reyero |
Comments
Comment #1
Gábor HojtsyFix tag.
Comment #2
Gábor Hojtsy#569004: Add support for seek based batch import of .po files is also related for the import, once the files are on our system.
Comment #3
seutje CreditAttribution: seutje commentedsubscribing
Comment #4
Gábor Hojtsy@Sutharsan already solved a great deal of this as part of his work with #568986: Dynamically update standard language list from localization server.
Comment #5
Jose Reyero CreditAttribution: Jose Reyero commentedSubscribing
Comment #6
Jose Reyero CreditAttribution: Jose Reyero commentedI'm starting to look into this task which has some important challenges:
- We need to check the info file for each component or for each project the component belongs to.
- I see no straight forward way to link a module to the project it belongs to.
- We need to add some table or at least some hook to store which file and version was imported. This will be important for any future update module later.
- There's some issue with locales/install order, see #571380: Manage localization on module install (import locales first, default language)
Comment #7
Gábor Hojtsy@Jose: on relating modules to projects, the update status module had and solved the same problem. :) So you can look up a possible solution there.
Comment #8
Jose Reyero CreditAttribution: Jose Reyero commented@gabor,
You're right about modules and projects and the update module. That should be moved to a common file, maybe install or update inc so it can be reused.
Now we need some storage to see which projects have been imported, which ones not... Also need to figure out how to handle fallback to the filesystem, which currently is per module files.
At this point I don't think we still want to use the old file structure (module/translations) as translations wont be packaged with modules anymore and we should move to something else, better if configurable along the lines of '/translations/module', or mimicing the folder structure in the core_translation module, http://drupal.org/project/core_translation
Also, should we move this file structure to per package po files too?
Comment #9
Jose Reyero CreditAttribution: Jose Reyero commentedThis is just the start: Move project handling functions (update projects) into a separate API so it can be used by the locale system too..
A lot of work needed yet. I'm thinking maybe posting this patch on a different issue, though this may be slow down the whole work...
Comment #10
podaroksubscribe
Comment #11
Gábor HojtsyOk, so since this one is not going to get into core, what we can do is to
(A) depend on update module to be enabled
(B) just include this single file and use its functions without requiring update module to be enabled (except the update.compare.inc file is not self-contained and is using API functions from outside, so it is not enough in itself)
(C) copy the code out and just use a copy
I'd say (A) is the easiest on us and is reasonable given how update module has these security features. I can understand that it being much extended in D7 with install and update, you might not want to have it enabled or tie this functionality to that module. In which case, looks like we need to fork out this fine library to make it work.
Not sure where to reposition this now that core will not get this functionality. Looks like l10n_client would be the good project to house this under. It has 6.x and 7.x versions both working hopefully equally, so we can start with either and build from there.
Comment #12
Gábor HojtsyMoving to newly added l10n_update.
Comment #13
Jose Reyero CreditAttribution: Jose Reyero commentedThe module includes now a full independent module/project api (so it doesn't depend anymore on update module) and we can have some extra features, like updating translations for disabled modules.
See l10n_update.project.inc
Comment #15
Gábor Hojtsy