Account created on 14 July 2009, over 15 years ago
#

Recent comments

🇳🇱Netherlands stefan.r

Even if we just list nodes in the standard content view, this still causes data loss in custom views.

So if just before release time we still don't have a fix, we should probably revisit this issue and just hide operation links/bulk operations from any view that includes translations.

🇳🇱Netherlands stefan.r

Some D7 screenshots, for reference:

@plach is this what we're trying to replicate? Or are we thinking of Entity Translation?

🇳🇱Netherlands stefan.r

The best defaults will likely depend on the use case again, if we want to stay close to D7 we could filter by "the displayed nodes have either a translation or an original version in the selected language", and not apply the filter by default (ie showing all languages).

🇳🇱Netherlands stefan.r

Yes that makes sense, I think D7 Adminstration Views retains this same behavior right?

In terms of this issue just a warning message on the confirmation screen would suffice I guess. If we want the "elect a new original" functionality, instead of a warning it could be a dropdown for every single source translation on that same confirmation screen, with some sensible defaults (either user defined or using already existing language weightings)

🇳🇱Netherlands stefan.r

Yes that could work as far as the main overview is concerned. We may still want a separate translation overview in that case.

🇳🇱Netherlands stefan.r

@aspilicious by "an extra row with all the language codes" you mean "a row for every translation of a node" or do you mean "one row with all the translations in them"? I think the different coloring could work.

What are your thoughts on addressing the translations issue in the main "Content" view vs. removing all the language-related stuff from the main "Content" view and adding another "Content Translation" tab next to it?

I also talked to @dawehner about somehow addressing the source translation deletion issue. The problem is when we delete a source translation all its translations are deleted, if they were to remain intact though the problem is what to do with these "orphans" that don't have an "original language" anymore. Just to illustrate, if the original node is in dutch and the translations are in french/english, we may want to be able to delete the dutch translation while still preserving the french/english ones.

Right now deleting a source translation is disallowed in certain spots of the UI but allowed elsewhere. One solution would be to disallow it everywhere (including in bulk operations, where we can warn about this in the confirmation screen).

🇳🇱Netherlands stefan.r

I had missed @dawehner's comment in #2 when writing this up. That actually sounds like a good way to solve this issue :)

🇳🇱Netherlands stefan.r

Just a few ideas on this as I dealt with a similar issue when asked to put a language filter on a D7 Administration Views overview (and perhaps these would need to be addressed in the second "multilingual" view if we remove the language filter from the current overview altogether):

- Solutions such as an "only show original" filter sound targeted to site builders and may be confusing to content managers, who often won't care whether something is a translation or an original and may want the filtering to fetch both.

- If the real concern is that deleting a source node kills off all the translations, maybe we could retain that behavior in code but work around this in the UI somehow. For instance with separate "delete" and "delete with all translations" options, where a regular delete would only delete the current translation. I don't know that we have a way to deal with orphaned translations yet, but it seems like a useful feature to be able to delete an original translation. This would also solve the UI WTF in the node edit form of the original where if you click delete it says "Delete (this translation)" but actually deletes all of the translations, and the delete button being hidden on the translation overview page for a node.

- Even with the deletion problem solved, the table length would still be an issue, but seeing all the translations would often be rather "just enough information" than "too much information" for a site with only 3-4 languages. It also only applies to the unfiltered view. There ought to be no need to hide translations from the _filtered_ view. Further, if we're still going to only show nodes in the _unfiltered_ view anymore just to make the table less cluttered, maybe we can still find a way to make the translations selectable, for instance by making the rows collapsible, with the nodes expanding to all of their translations.

Production build 0.71.5 2024