i18n_string: Textgroups in translation import have been removed from core

[indigoxela]

i18n_string: Textgroups in translation import have been removed from core

[herbdool]

Just spun up a core d7 site and compared with Backdrop core and I see what you mean now. I haven't looked further into this but wondering what is the difference between textgroup and context and why it was taken out (I assume this happened early on in d8 dev).

I think I'd need to see the historical discussion to decide on whether it's something to bring back or not.

[indigoxela]

what is the difference between textgroup and context

Context is used for t() to prevent overlapping translations (ambiguous / short strings).

Textgroup is used by i18n (don't actually know any other module) to separate/split export and import and string refresh (textgroups seem pretty important for i18n_strings).

Yes, that was ripped out pretty early in D8: https://www.drupal.org/project/drupal/issues/1188430

But I think it has some value.

[herbdool]

There's a lot to digest. I'd be curious to know what Gabor thought was the better option for d7 if not textgroup.

I guess there are two approaches in my mind:

1. implement textgroups in i18n for it's own modules so that it makes it easier to get it all up and running. So far it seems like core works well enough without it. Longer term find a way to deprecate textgroups for somethng better (whatever that is).
2. Or, find a way to strip out all textgroup functionality from i18n. Perhaps the location column could be used better instead (from what I gather in this part of the thread https://www.drupal.org/project/drupal/issues/1188430#comment-4626010).

[herbdool]

Looking into this again (while looking into webform_localization which relies on i18n_string sort of). This issue might provide a clue to what we could do to move away from textgroups if we decide to leave them out: https://www.drupal.org/project/i18n/issues/1191662

Steps:

• We need to create a 'i18n_string_text' table and move all the translations there, included the source language. So we'll have a 'i18n_string' with string metadata and 'i18n_string_text' with source text and translation for every language.
• Rework the data storage and retrieving functions that will be simplified by this new schema. Luckily most of this has been encapsulated now on i18n_string_textgroup_default class.
• Note: i18n_string_text table will need a 'format' field, so we can fix too that text format related issues.

[herbdool]

I'll note that Jose didn't end up finishing those steps because he said it was a "major rework of i18n_strings" and he wanted a stable release soon. So it seems possible but not a small job.

Either way it seems that we'd need an upgrade path for textgroups. So perhaps we just bring them back and, if we agree, to do the rework of i18n_string later.

[indigoxela]

Whoa... refactoring i18n, or just i18n_string, is probably something we won't be able to do. We don't have enough time and people for this. And I don't think that it's worth the effort anyway. Please note that the export by group works, but the import ignores groups.

If I had enough time, I'd rather start fresh and do something way simpler than i18n - which is a complex beast with a terrible UX.

[indigoxela]

Reverting my workaround for missing textgroups might be a little more work than I hoped:

• 3853296
• b40ddc5
• 0bd2376

Above list is probably incomplete.

[herbdool]

Your workarounds were to support textgroups in i18n instead of in core? I guess that's a possibility too. Just didn't seem easy since there were a number of function signature changes. What do you think @indigoxela ? Do you prefer putting it back in core or keep workarounds here?

[indigoxela]

Do you prefer putting it back in core or keep workarounds here?

I wish I could tell... 😉

[indigoxela]

I wish I could tell

I made up my mind: handle it in i18n. Waiting for core makes things even more difficult.

There will have to be some cleanup in the import form. - That's the only remaining task here.