Problem
The current process of manually importing translations by means of po files is not an optimal user experience and requires many individual steps which are not self explanatory. Think you run a site with 40 modules and 3 foreign languages. You'll need to download 123 (3*40 for contrib and 3 for core) translation files and check them for updates manually.
Goal
An automated process to import and update interface translations when a site is installed, build and maintained. The functionality provided by Localization Update module is therefore required to be in Drupal core.
Sub-issues
#1029554: Translations update feature user experience
#1260586: Consolidate .po file import to one directory
#1189184: OOP & PSR-0-ify gettext .po file parsing and generation
#1627006: Collect project information for translation update
#1632384: Import available language list from translation server
#1635084: Track import status of files in the locale .po file directory
#1742894: Get status of local and remote translation files
#1804688: Download and import interface translations
#1804702: Display interface translation status
#1848490: Import translations automatically during installation
#1998056: Automatically update interface translations using cron
Follow-up issues
#1293252: locale_language_insert() and locale_language_update() should only have local cache side effects
#1774024: Create helper function to find release info for a project (follow-up issue to locale collect project information)
#1774032: standardize gettext, .po, po terminology (follow-up issue to locale collect project information)
#1777106: Make check for out of date project update information more robust for sites that are not running cron regularly (follow-up)
#1777126: Have locale and update module share/reuse code for version name parsing
#1787520: Translations not imported on installation
#1832946: Runtime translation download fallback works different from installer translation download fallback
#1834298: Unify name space in Locale module
#1842362: Replace locale_project table and improve caching
#1842380: Convert $source object to a TranslatableProject class
#1861360: Refactor localization update test so people can just enable the test module to test
#1861930: Use "Drupal translations website" instead of Drupal translation server or Community translation server
#1861934: Rework help text for UI translations and importing po files
#1884996: Progress of Import translations automatically during installation goes to warp speed at the end after 60%
#2021749: Core should not force latest version number translations on sites
Details
The below state diagram describes the processes involved in this automated process.
The following use cases should be supported:
- Install Drupal with one language other than English
- Install Drupal as part of an installation profile with one or multiple languages
- Add/remove/update modules
- Add/remove/update languages
- Update interface translations manually and automatically (cron)
- Use local po files and/or remote translation server as translation source.
- Respect existing local translations and/or translation changes when importing and updating
Comments
Comment #1
Gábor HojtsyFix title typo :)
Comment #2
Sutharsan CreditAttribution: Sutharsan commentedsubscribing
Comment #4
Gábor HojtsyI've documented how this fits to overall Druapl 8 plans at http://groups.drupal.org/node/161589.
Comment #5
Bojhan CreditAttribution: Bojhan commentedsubscribe
Comment #6
Gábor Hojtsy#1260586: Consolidate .po file import to one directory opened as sub-issue to start this off.
#1029554: Translations update feature user experience already exists as a sub-issue.
Comment #7
plachComment #8
podaroksubscribe
Comment #9
droplet CreditAttribution: droplet commentedsubscribing
Comment #10
Gábor HojtsyNow that #1260586: Consolidate .po file import to one directory landed, I've submitted #1329410: Extend update data collection to support localization update as a good next step to work on for this. Please help there!
Comment #11
Gábor HojtsyDismantling meta issues to clean up the D8MI issue list. (Working on a better overview for the issues).
Comment #11.0
Gábor HojtsyAdd sub-issue
Comment #12
Sutharsan CreditAttribution: Sutharsan commentedRe-opening the issue as meta issue for the Localization Update integration currently being worked on during the D8MI sprint in Barcelona.
Comment #13
Gábor HojtsyUse D8MI so it shows up on our board too.
Comment #13.0
Gábor HojtsyRewritten issue summary
Comment #13.1
webflo CreditAttribution: webflo commentedUpdated issue summary.
Comment #14
andypostAll patches are introduces new variables so we need consistency in naming for #1714462: Convert language negotiation settings to configuration system
Comment #15
Gábor HojtsyNow #1627006: Collect project information for translation update is committed, but there is some important followup work going on there. #1742894: Get status of local and remote translation files is being worked on. Help there is appreciated.
Comment #16
Gábor HojtsyAdd back lost D8MI tag. Removal of sprint tag was intentional so we can focus on the specific tasks.
Comment #16.0
Gábor HojtsyReference to #1742894 (new issue) added.
Comment #16.1
Sutharsan CreditAttribution: Sutharsan commentedAdded #1804688: Download and import interface translations and #1804702: Display interface translation status
Comment #17
Gábor HojtsyAll right, all sub-issues listed above are done! #champagne :)
Any issues missing? :)
Comment #18
plachAwesome awesome work, guys!
Comment #18.0
plachUpdated status
Comment #18.1
Sutharsan CreditAttribution: Sutharsan commentedAdded follow-up issues.
Comment #18.2
Sutharsan CreditAttribution: Sutharsan commentedCron issue added to list of sub issues.
Comment #18.3
Sutharsan CreditAttribution: Sutharsan commentedUpdated issue summary.
Comment #18.4
Sutharsan CreditAttribution: Sutharsan commentedUpdated issue summary.
Comment #19
penyaskitoI was very tempted of adding D8MI tags to #2045977: Bring l10n_update commands in Drush core, but that's a Drush issue. So just catching your attention there in the meanwhile.
Comment #20
Gábor HojtsyI think this should be mighty fine to close as fixed at this point.