search

backdrop-contrib / i18n

Collection of modules to extend Backdrop CMS multilingual capabilities
https://backdropcms.org/project/i18n
GNU General Public License v2.0
2 stars 5 forks source link

[META] Migration path from D7 #33

Closed indigoxela closed 3 years ago

indigoxela commented 4 years ago

These modules need a migration path, as functionality made it into core (or has gone or changed significantly).

Pick your task, open a new issue, link it here...

Basic descriptions of TODOs (so far):

i18n_user https://github.com/backdrop-contrib/i18n/issues/47

Now in core (user.mail.json). Move from variable_store db table to locale module db tables with translation context pattern like config:user.mail:[name]

i18n_block https://github.com/backdrop-contrib/i18n/issues/35

Needs a migration path from locale db tables to block.custom.[name].json (custom blocks only), Needs to run after system 1025 (see: hook_update_dependencies()).

i18n_variable https://github.com/backdrop-contrib/i18n/issues/48

Migrate "Site details" (system.core.json) from variable_store to locale db tables with translation context pattern like config:system.core:[name]

    "_config_translatables": [
        "anonymous",
        "site_name",
        "site_slogan",
        "maintenance_mode_message"
    ],

Then drop db table variable_store? Maybe other i18n variable stuff could get migrated?

i18n_taxonomy https://github.com/backdrop-contrib/i18n/issues/34

Core now takes care of term language/langcode. So data from "language" column should get moved to "langcode" column.

i18n_menu https://github.com/backdrop-contrib/i18n/issues/34

Move data from "language" to "langcode" column in table menu_links.

There's probably even more to do, but these tasks are tricky enough.

Especially the moving of translations from db tables to config or to other db tables. Module locale provides no helper function for that and i18n_string is unusable in this case, as the translation group is the default one ("Built-in interface").

Any hint is welcome.

herbdool commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

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

herbdool commented 4 years ago

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 commented 4 years ago

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 / _variablestore 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 commented 3 years ago

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

herbdool commented 3 years ago

I created https://github.com/backdrop-contrib/i18n/pull/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.

indigoxela commented 3 years ago

@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 https://github.com/backdrop/backdrop-issues/issues/4888. I'd prefer to remove it before merging the branch, if possible.

herbdool commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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):

Both are unrelated to this issue here.

indigoxela commented 3 years ago

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

indigoxela commented 3 years ago

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 720902d1

indigoxela commented 3 years ago

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.