[META] Migration path from D7

[indigoxela]

[META] Migration path from D7

[herbdool]

I created #59 which is just comparing your update branch with 1.x-1.x, and added comments.

I've tested the upgrade branch and it worked fine for me - I used a D7 client site with a few i18n modules enabled.

[herbdool]

So this issue is just about the data? There's also issue about some additional functionality that some of these modules provide that's not in core but I assume there will be other issues to deal with those?

[indigoxela]

So this issue is just about the data?

Yep, it's about data migration when upgrading from D7.

There's also issue about some additional functionality that some of these modules provide that's not in core but I assume there will be other issues to dry with those?

Ehm... I'm afraid I don't get what this means. Sure, this suite of modules enhances core multilingual support. That's why we still need it. Or... what am I missing (or misunderstanding)?

[herbdool]

I mean if you've got other github issues to deal with decisions on everything else other than the data migration - so don't need to discuss that all here.

It might be easier to help if each sub-module had it's own github issue - break up the above info into its own issue. Some seem easier to deal with than others. For instance, I think taxonomy might be easier than users.

[indigoxela]

It might be easier to help if each sub-module had it's own github issue

Ahaaaa, now I get it. 😉 Sure, this one here could be a meta Issue for the respective Issues per submodule.

[herbdool]

Makes sense.

I wanted to add a comment regarding i18n_user and 18n_variable, we had added the context in Backdrop. So it's still possible to match them up without the context pre-existing in D7?

[indigoxela]

So it's still possible to match them up without the context pre-existing in D7?

That's why it's tricky. The first task is to get the string from variable / variable_store db table with proper context (like "config:system.core:site_name") into locales_source, then get the translation with corresponding lid into locales_target. The lid won't exist until locale picks the need for translation up (via t() or maybe locale()).

Sort of how function _locale_import_one_string_db() does it. Textgroups are irrelevant in this case (user mail texts, site config translatables), as these strings are now in group "default" for which i18n_string isn't responsible.

Different contexts or no context won't match.
An example:
t('Teststring')
and
t('Teststring', array(), array('context' => 'my:custom:context'))
get handled as totally different strings.

[indigoxela]

Migration paths should be working now. Still needs a little more testing, before I merge this branch: https://github.com/backdrop-contrib/i18n/tree/d7-upgrade-path

[indigoxela]

@herbdool Many thanks for your comments, I've updated the branch.

I'm still not sure, how to proceed with the workaround for core bug backdrop/backdrop-issues#4888. I'd prefer to remove it before merging the branch, if possible.

[herbdool]

Maybe it's not a big deal to just leave the update hook in this module too until then. I'm interested in getting an official release soon either way.

[indigoxela]

I'm interested in getting an official release soon either way.

I get your point. What's the time window you have for your site upgrade? Would it be helpful, to merge the branch into 1.x-1.x, or do you really need a release (alpha or beta - it could be too early for stable)?

[herbdool]

I say merge into 1.x-1.x. and I can use that at first.

What are the roadblocks to getting an official release? Can we represent them as individual issues here? And close off some of the ones already done?

[indigoxela]

I say merge into 1.x-1.x. and I can use that at first.

Done. (I didn't squash, as the change is rather big and I wouldn't want to lose the individual commit messages.)

What are the roadblocks to getting an official release?

For my understanding it's mostly the core bug workaround, that I wouldn't want to include as-is in a release.

But there are other things on my todo list, I'd like to address before a stable release (no show stoppers for an alpha, though):

• Check compatibility with a recent core change: #37
• Cleanup po import form (contains useless items): #17

Both are unrelated to this issue here.

[indigoxela]

The final todo in this issue is to merge branch "remove-workaround-4888" as soon as the problem is fixed in core. Blocked by backdrop/backdrop-issues#4888

[indigoxela]

Oops, one more TODO - also run the schema change from locale_update_1005() (switch from blob to text), as core might not have a chance with the "hidden" shadow copy of tables.

That has been fixed in 720902d

[indigoxela]

I did some final testing after the latest merges - it seems, we're done with the upgrade path.

Additional testing is, of course, always welcome.