Closed (duplicate)
Project:
Drupal core
Version:
8.3.x-dev
Component:
migration system
Priority:
Minor
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
4 Jun 2015 at 15:16 UTC
Updated:
13 Mar 2017 at 22:21 UTC
Jump to comment: Most recent
Comments
Comment #1
svendecabooterI guess this is being tackled in child issues of #2208401: [META] Remaining multilingual migration paths?
Comment #2
steinmb commentedNot in the meta issue it self but in all those child issues by added to it. Not sure if there is settings in locale that need special migration, if yes, I'm pretty sure it will be done in here.
Comment #3
quietone commentedComment #6
gábor hojtsyWith #2353709: Variables to config: language.types [d7] and #2225293: Migrate D6 and D7 language negotiation settings following up after #2130307: Variable to config: language.negotiation [d7] and #2353761: Variable to config: locale.settings [d7], what else is left here? I assume we do NOT want to migrate the string translations themselves. We are migrating i18n strings (also stored in the locale tables) in individual issues like #2225717: Add config translation support to migrations and implement for Drupal 6 user profile fields but do we want to keep the string translations? Drupal 8 should download those for the modules/themes installed, so only custom code may be concerned here. OTOH we cannot tell which strings came from custom code and this is a fantastic opportunity for people to clean up old cruft.
Comment #8
damienmckennaAdding the main D7-D8 issue as a related issue.
Comment #9
gábor hojtsyI still hold my opinion/question from #6.
Comment #10
mikeryanIn response to Gabor's question - silence implies consent (that there's nothing left to do here, with the doable parts already done elsewhere)?