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

Views and i18n [meta] #52

Closed laryn closed 2 years ago

laryn commented 3 years ago

Pulling out a few comments from an earlier thread:

@laryn: Should i18n Views be wrapped (back) in since Views is in core now?

@mazzech: I used i18n Views several times, there are a few hickups, but the workarounds without the module are pretty dirty... ++ for having it migrated:-)

@indigoxela: Regarding i18n Views: I never needed it because views labels and header/footer text areas are translatable as-is, without any additional modules. At least in D7 - didn't need it yet in Backdrop. But if it works in D7, it should work in B core (or we should fix it there).

herbdool commented 3 years ago

Are you suggesting putting that module into this one? Or port it with dependency on i18n?

laryn commented 3 years ago

@herbdool My question is whether it should be merged into this module -- mostly because Views is in core now. If I read it right, it used to be part of i18n and was at one point removed:

This module has been moved from Internationalization package so we can have different branches compatible with each of the Views versions.

indigoxela commented 3 years ago

The first thing I'd check: isn't i18n_views obsolete?

Views strings are translatable again since B 1.16.3. Before we put any effort in this, we should verify that it's really necessary.

laryn commented 3 years ago

I've come across a situation where pieces of i18nviews are needed. I think perhaps we can just pull out the relevant handlers and add them directly to the appropriate submodule in i18n rather than requiring a separate i18nviews module.

The port that is working for me on this dev site in question is here: https://github.com/laryn/i18nviews

Maybe we can just pluck pieces out of there as we need them. @indigoxela says "Most of the other stuff just duplicates everything that core and i18n already provide."

herbdool commented 3 years ago

Some of i18nviews may need to go into core too since basic localization and views are already in core. We'll need to figure out what goes where.

indigoxela commented 2 years ago

TBH, I'm a bit unhappy with this meta. In Drupal i18nviews is an extra module.

The i18n suite is a monster on its own, and not so easy to maintain. Incorporating other modules, which includes migration paths, is a little much for the small maintainer team (cough) of i18n.

laryn commented 2 years ago

I get it, and you're the boss.

laryn commented 2 years ago

One case where I've found I need to use the i18nviews functionality is on exposed filters for taxonomy terms. For example, you want filters that people can select but you want to use the localized version of the term names.

@indigoxela should I close this issue and open a core issue to see if this is something that might be possible for core inclusion (and if not just finish the i18nviews port and release that? Or do you think that functionality belongs in i18n?

herbdool commented 2 years ago

I think the best is to do the i18nviews port. Translating views gets complicated quickly.

indigoxela commented 2 years ago

I'm not really familiar with i18nviews. Plucking out pieces might make it even harder for maintainers and users.

Taxonomy terms are already tricky, because some functionality re term translation went into core and now things overlap a bit. But rewriting i18n is above my head (and available time).

So, for now it's probably best to fully port i18nviews.

laryn commented 2 years ago

Will do. Thanks.