If you use Entity Translation instead of Content Translation, you don't need the Multilingual content module (i18n_node), which is even incompatible.
But then, you can't translate content type strings such as content type name, which is something handled by i18n_node_translate_type() and other functions. See #2107219: How to translate content type names? for more info.

CommentFileSizeAuthor
#1 i18n-decouple_node_type_strings_translation_from_node_translation-2108063-1.patch21.1 KBgaëlg

Comments

gaëlg’s picture

gaëlg
he/him
Primary language French
Location Lille, France
commented
Status: Active » Needs review
StatusFileSize
new i18n-decouple_node_type_strings_translation_from_node_translation-2108063-1.patch21.1 KB

Here are the main changes. I called the new submodule i18n_node_type and made i18n_node independent from i18n_node_type, only using module_exists('i18n_node_type') in a few places.
Not to hard to do but hard to review I guess.
If this patch is good enough, the remaining work is to update the .install and .test files if needed (I'm not very sure about what to do with them).
Thanks in advance for your attention.

jose reyero’s picture

jose reyero commented

I think i18n_node and ET should be compatible, unless you try to translate the same content type using both...?

Possibly we'd be better off just fixing the incompatibility if any.

gaëlg’s picture

gaëlg
he/him
Primary language French
Location Lille, France
commented

Even if they might be compatible, which is not what plach said in #1852102: Clarify that Multilingual Content (i18n_node) and ET are not compatible, it's a bit useless (and confusing in the admin UI) to use the whole i18n_node code to only make node type strings translatables, which is a completely different goal. If it can be compatible, it should be documented better.

jose reyero’s picture

jose reyero commented
Status: Needs review » Closed (won't fix)

You mean you haven't tried? Then maybe you should start by documenting such incompatibilities which I haven't seen anywhere and we may try to fix that.

Having both modules bundled together makes the whole thing really much easier to maintain and API changes are not really a good idea this late in the development cycle.

gaëlg’s picture

gaëlg
he/him
Primary language French
Location Lille, France
commented

I tried on a previous project I made and got this bug: #1669494: Selecting language in new node and saving, keeps node language neutral, which ends up with a "works as designed" because of the incompatibility between the two modules. I did not need content type translation because my content editors spoke the same language.
But now I need it and remembered of that incompatibility problem. Actually, the modules are very probably compatible in some use cases, or just need some patches for other cases. I don't really know. There are many settings combinations possible. But it looks like this compatibility is at least "unsupported".
I had two options: enable the two modules and try to fix any encountered problem, or enable Entity Translation only and make a patch like this. What I faced on previous projects and what I read about the "incompatibility" scared me a bit about the first option. And it looks like enabling both modules result in more unnecessary complexity, which is probably the reason why they tried to make ET NT-independent:

I think we now have the all features provided by "multilingual content" in ET core (correct my if I'm wrong)... can we close this as "works as designed"?

Obviously it's wrong.

I understand your reasons about not to change the code this late. I just wanted to try to fix that problem for all users. I guess many people found a workaround for there own use case but did not share.
Anyway, this is something that has to be discussed with ET maintainers. What are people supposed to do if they need ET translation + content type translation? Enable one or both? I'll suggest that plach read this post. Many thanks for your attention.

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
commented

My bad: I got confused between Multilingual content and Multilingual select, IIRC they were both part of the same module in D6. The former should be fully compatible with ET or at least I don't see any architectural incompatibility.

+1 on closing this issue.

kopeboy’s picture

kopeboy
Primary language Italian
Location Milan
commented
Version: 7.x-1.x-dev » 7.x-1.11
Component: Miscellaneous » Compatibility
Issue summary: View changes
Status: Closed (won't fix) » Needs review

I am sorry guys to reopen this but I didn't get how I should translate content types labels/settings when configured to be translated with Entity Translation.

While Field translation works together with ET, Content translation doesn't.

For example, I'm using Italian as my default language, with detection = URL prefix (nothing for italian, en/ for English).
If I create a node and try to translate it (en/node/xxx/edit/add/it/en or whatever) I get a redirect loop.
If I manually input the path to be /node/xxx/edit/add/it/en I can add the translation, but then when I visit my node and click on the English link for the interface translation (link is en/node/xxx from node/xxx) I get the redirect loop.

I noticed that to get this working, the "Source language" setting at admin/config/regional/i18n/strings must be the opposite of the Language you select in the add node form for the content you are creating :/ weird and of course not usable.

I re-opened the corresponding issue in ET issue queue: https://www.drupal.org/node/2107219#comment-9049015

kitikonti’s picture

kitikonti commented

@GaëlG because this is still not working i want to use your patch, or exactly i want to create a own module. i dont want to patch the i18n module i just want to create a standalone module to translate the content type names. the question now is, is this possible? you wronte about some module_exists you have added to the i18n_node module. do i need them?

kitikonti’s picture

kitikonti commented

So i created a new sandbox module from your patch. So you dont have to patch i18n. I also added localized tokens for the name and the description. Currently i dont have any problems with it on my dev site.

jose reyero’s picture

jose reyero commented
Status: Needs review » Closed (won't fix)

So... if anyone can find those incompatibilities, we'll try to fix them but about the feature request here, just "won't fix".
There are other questions in this issue... do read the docs /update the docs.