I think using the same module name as core's translation module is not a very good idea. As I see it, both approaches could coexist for the same site, maybe you want some content types with translated fields, some others with node translation.

Just by changing the module name we could explore these other options, which won't happend if both modules are mutually exclusive.

Comments

sun’s picture

We discussed this quite lengthy already, and were not entirely sure at the beginning, but in the end, we figured that the goal of building the replacement module for Translation module in D8 during the D7 release cycle using the same module has precedence over supporting backwards compatible features, which are still part of the module (but in an optional sub-module), but (IMO) very likely to be removed in the near future.

In addition to that, D7 allows version-specific dependencies, so modules that only work with the stock Translation module in core can state (=1) in their dependency info.

Jose Reyero’s picture

The replacement module for translation doesn't need to be named translation. And that version number may change.

I was thinking only that both features (core translation, contrib translation) may co-exist (in the same site), unless we have a reason to block that option.

So I'll put the question some other way: do we have any reason to block the option of using both modules at the same time?
(Which doesn't mean you, or me, want to use it, just that someone may want...)

sun’s picture

The version of the stock Translation module in Drupal core is very unlikely to change from 1.*, since major versions of modules in Drupal core never changed thus far, only the major version of Drupal core changed.

This module will purposively use a major version of 2.x.

As mentioned before, the current plan foresees to keep the functionality of core's Translation module as an optional translation_node sub-module, and if I understood plach correctly, then a site admin will be able to declare which translation system to use for a node type. In the long run, however, translation_node does not make sense, because it's limited to nodes, and D7 talks entities instead of nodes. So regardless of translatable fields, we will have to discuss the potential need for a more generic translation_entity sub-module -- in case there is ongoing interest in this translation method at all.

As of now, I don't see a problem with replacing the namespace. There's even a mostly working upgrade path already.

plach’s picture

@Jose Reyero:

So I'll put the question some other way: do we have any reason to block the option of using both modules at the same time?

As sun was pointing out, in the initial release of Translation we are including a straight copy of the core Translation (with the minimal changes needed to make things work). This may change in the next branches as long as the module evolves.

Since the goal of this project is building a module capable to replace core Translation in D8, it's better for us to collect use-cases and make everyone of these covered by Translation 2. This is why we prefer to avoid the possibility of using both core Translation and Translation together.

Rather we want to cover (or at least support) all the possible needs, as pointed out also in #778528: Define the language switcher's correct behavior.

plach’s picture

if I understood plach correctly, then a site admin will be able to declare which translation system to use for a node type.

Exactly

Jose Reyero’s picture

Status: Active » Closed (works as designed)

Ok, it seems I got the idea wrong.

If this is an extension of core translation, then it can make sense to reuse the name. However I think we need to be very careful with the API provided by this module so it is backwards compatible with core's translation. Then we can have a drop-in replacement with some extensions, which will be fine, though it can make this module very complex.

plach’s picture

Gábor Hojtsy’s picture

Status: Closed (works as designed) » Active

I've opened an issue at #1046208: Rename base module to field_translation or somesuch about basically the same thing. While reviewing the module, I found the following issues with it:

- the core module certainly has use cases this module does not fulfill (yet); this is also agreed on by plach at http://randyfay.com/comment/684#comment-684
- if you just enable the contrib translation module "install as usual" as written in the README does not really apply; you'll need to run update.php to actually install the module
- the project needs to include a whole copy of the core module little of which it overrides (and which can be overriden with alter hooks, right?), and given @sun plans to remove the module altogether, it looks unlikely it will get much developer attention to deviate further

I think the theoretical easiness of rolling Drupal 8 patches, that necessiates the current module name choice is not worth the obscure module install process and managing duplicate code with core, does it?

(Also, I'm working on an article about this module and trying to reference core translation module vs. contrib translation module is really painful, a real identity for this module would be good :)

Gábor Hojtsy’s picture

Also, *contrib* translation module itself includes functions with the translation_node prefix, which makes the namespaces with the contrib translation_node module overlap in possibly confusing ways.

Jax’s picture

Having a contrib module with the same name as a core module is confusing as hell. How are you going to handle support or other questions? Beginners won't be able to answer the question "Are you use the core or contrib translation module?".

"Node translation" is called "Content translation" by core and "Field translation" is called "Content translation" by the contrib module. How much more confusing can it get?

plach’s picture

I'd like that everyone wishing to contribute to this discussion had a look to #539110-85: TF #4: Translatable fields UI and following: this is where this issue was originally discussed. You might find answers to your questions (hint: core dependencies, among the rest).

That said I am wrapping my mind around this again and I hope to come up with a sensible post summarizing pros and cons of this choice, which on my side can still be reverted, but we must do it now, because later might be an impossible/overwhelming task.

I'm rethinking about this once again only because two of the most prominent i18n team members are against the current choice. I'd like to read sun's feedback too.

Gábor Hojtsy’s picture

@plach: well, I think the problem in short is that the core translation module works with forming a group of entities, while the contrib module works within an entity with a "tree"under it, and the two models are not compatible (you need data migration code to move from one to the other). They are two different approaches, and the contrib module does not approve the validity of the core approach. That is fine. Basically the contrib module is not an advanced version of the core module, its a different approach. It should have a different name to distinguish itself. That does not make it less likely to get into core as a replacement for the core module I think. That will mean you'll need to have bigger patches to rename stuff, but the whole module is a different approach, so its already a big patch, not much of a difference, is it?

plach’s picture

Ok, I've been reading almost everything was written about translatable fields in the core queues, in our mail discussions and on Gabor's and rfay's blogs. After coming back from those writings my gut feeling is we have far more interesting challenges ahead than discussing about the module's name, which is sort of bikeshedding in my mind. Let me tell you why, but let's examine pros and cons first:

Note: from now on I will refer to the contrib module as "Translation 2" (yes, this is a con without a pro).

We are confusing our poor users!

"Node translation" is called "Content translation" by core and "Field translation" is called "Content translation" by the contrib module. How much more confusing can it get?

By replacing a core module we are introducing a fairly unusual situation AFAIK: people will have to learn how to properly install Translation 2 (not an overwhelming task after all) and might ask themselves why the heck we didn't go the Profile 2 way. OTOH by having a unique (albeit contrib) solution we would avoid our users the feeling that there are different, possibily clashing, alternatives: content translation is just one module offering different approaches as many many other do.

OMG, handling code is going to be a nightmare!

I think the theoretical easiness of rolling Drupal 8 patches, that necessiates the current module name choice is not worth the obscure module install process and managing duplicate code with core, does it?

In the early stages of Translation 2 development I had to work a lot to have both module coexisting in the same project, and we will probabaly have to backport core patches to Translation 2 once committed. No doubt this is pretty annoying. Moreover we will have to figure out the best way to preserve the core (legacy) API in order to integrate with i18n, which shouldn't be that hard, however. The good news here would be that if we were able to convey most users to Translation 2 we would have a unique issue queue where coordinate the development, fix bugs, and collect uses-cases/feature requests. Moreover language handling in the node administration page would keep working even without having node translation enabled, which would be impossible otherwise.

Hey, you! Get your damn hands off her!

They are two different approaches, and the contrib module does not approve the validity of the core approach.

Apart from the reasons mentioned above, it seems there is a (probably justified) concern about a couple of evil guys :)) wishing to kill the poor node translation system without providing any viable alternative. I have to admit this was in my plans when I started working on TF (and it seems in sun's too), but in the meantime I had to once more realize that everytime we talk about internationalization there is no way to find a unique, supersmart, one-size-fits-all solution. That is I realized that atm we have no real proof (maybe some evidence ;) that field-based translation is a better system than node-based one: we just have two alternative approaches covering different uses cases. I have no problem to admit that field-based translation will always have problems to handle translations as first-class citizens. OTOH node-based translation will always struggle against the need of synchronizing shared data and handling different translations as a single resource.

So what?

To summarize: I don't care that much if we keep Translation 2 as a replacement or if we rename it: I still have the feeling that building an enhancend version of Translation would be easier if we had the possibility of fully replacing any line of its source code, but in the end who cares? Let's build an awesome solution exploiting the best both approaches have to offer and live happy with it :)

Just a last remark. In my mind the approaches we are dealing with are in-entity translation and entity translation: field translation and node translation have a far too limited scope.

Gábor Hojtsy’s picture

Yes, let's leave the core module alone. This contrib project works on an alternate solution that cannot replace the functionality of the core module, yet it replaces the module itself. Let's make this useful for our users.

plach’s picture

This contrib project works on an alternate solution that cannot replace the functionality of the core module, yet it replaces the module itself.

Since a long time I have come to think to Translation 2 as the place where address all the content translation needs. IMO we should stop identifying it with field translation, which is only the primary means to support one of the approaches it will implement.

I'll be even more explicit now.

@Gábor Hojtsy, @Jose Reyero: are your concerns about replacing the core translation module still pending? Do we need to rename Translation 2?

@sun: are you ok with renaming Translation 2, if the request is still valid?

plach’s picture

Just a side note: if we rename Translation 2, we probably won't be able to replace node translation functionality with entity translation without requiring users to disable core Translation.

Edit: and we will need to support the legacy translation API to integrate with i18n anyway.

Gábor Hojtsy’s picture

Yes, the way usual contrib modules override core functionality is to either ask the user to disable stuff or override menu items, etc. Views can override the default node listing, but it will not have a node.module to do that :) Asking the user to disable a module would in fact be a clean way to implement the same solution differently, since the user would be aware what is happening. Now if I try this contrib module, it provides me an upgrade path, from where there is no way back ATM, and then I loose functionality I could have used with the core module. Once again, it is not an improved version of the core module, it is a 100% different approach. Why would you name them the same?

Also I don't see why field translation is not a good name for this module. I've read in the issue queue multiple times that you are about to deprecate the entity set based translation model entirely. I think other contrib modules have space to get that on.

plach’s picture

[...] I loose functionality I could have used with the core module. Once again, it is not an improved version of the core module, it is a 100% different approach. Why would you name them the same? [...] Also I don't see why field translation is not a good name for this module. I've read in the issue queue multiple times that you are about to deprecate the entity set based translation model entirely.

Honestly I'm a little bit confused: I thought I had made myself understood with #13 and #15 but obviously I didn't.

My personal roadmap for content translation, which won't be implemented if there is not full consensus among us, is:

  • Translation 7.x-2.x-dev

    Both translation approaches are available. You can choose between in-entity translation or node translation for each content type. Node translation is kept as-is, the only difference is that in-entity translation is the default now and node translation must be enabled separately (we can discuss this too).
    The update function in translation.install just creates the translation table which is needed by in-entity translation to work. This is a fully reversible db change: if Translation 2 gets uninstalled, core Translation keeps working as Translation 2 never existed (for node translations, obviously).
    The translation upgrade is completely optional and might support rollback, if we should need it, since we have a history table used to keep track of the upgraded node translations.

  • Translation 7.x-3.x-dev (or whatever)

    Both translation approaches are available. We entirely abstract the concept of Translation and Translation sets (I'd say through OOP, but this is another issue), even in-entity translations might be considered part of a translation set. Both approaches and possibly others (say fields shared accross translation sets) become pluggable translation methods that can be enabled/disabled separately and possibly coexisting for the same bundle. We might want to keep some code letting users migrate data between the various translation methods.

The fundamental point is we develop the two approaches together and try to reach a better and better integration, also on the UX side. Every Drupal user knows that the "official" project dealing with content translation is just one, like Views is the only "official" query builder we have, although extended by gazillions of other projects.

Please note that in the D7 life cycle we don't drop/deprecate anything. Maybe in D8 we will have an indication of which approach covers more use-cases and we will be able to choose only that one for core, but in no way we will be forced to make this is step.

Please not also that the above roadmap can be implemented also if we rename Translation 2, it's just more difficult.

Gábor Hojtsy’s picture

Well, the owner of this module is @sun. He said this repeatedly:

http://drupal.org/node/132075#comment-1960068
"Personally, after intensively discussing the translatable fields approach with some site owners of multilingual Drupal sites, I do not see any use-case for the "old" node translation set based approach anymore."

From above:
In the long run, however, translation_node does not make sense, because it's limited to nodes, and D7 talks entities instead of nodes. So regardless of translatable fields, we will have to discuss the potential need for a more generic translation_entity sub-module -- in case there is ongoing interest in this translation method at all.

As far as I understand @sun does not see a use case for relating nodes or even entities for that matter in sets. I did take his word as the official plan for this module, because he is the maintainer. I see your roadmap is different, so looks like plans are not in line there? I understand you want to keep all translation features in this module, however, if we cannot even agree on a sane name for the module, its hard to envision we will have the level of consensus to work on one module to rule them all.

Currently, the project is named translation and the base module replaces the core module with 100% different functionality. This is insane. All right? I cannot say this more simply. For this module to work like a normal contrib module, it (a) should not use the name of the core module (b) even if there is a very good reason to do so, only use it if it provides the same functionality like the core module does possibly enhanced (or why would it have the same module code, if it would not be enhanced).

The current situation is like if we'd release fivestar or flag or whatever under http://drupal.org/project/poll, because these are better modules to do polls. Its confusing for *everybody*. Even if the mentioned modules aim for core inclusion in Drupal 8, and they can be used to achieve similar functionality, they are not the same. They are both more and less, ok? They are different!

I think we wasted entirely too much time on this issue, and would really prefer to do actual work instead of arguing about this. If this module aims to be a generic translation solution despite the often stated thinking in its issue queue that entity translation should be killed in favor of field translation, then we need to find a better name for it compared to core's.

We can name this module suite entity_translation (which would still make sense if it has field translation capabilities, after all the module certainly would not want to dabble into translating anything but entities would it?). However, it might aim to provide a generic solution for entity translations of all kinds (either above or under the entity level). We can call it content_translation, or whatever.

My basic point is that this module should call itself ANYTHING BUT translation.module. It does not make ANY sense to call it translation module for development, documentation, and especially user's sanity. It does not make sense even with your updated roadmap.

plach’s picture

ok, sun?

plach’s picture

Status: Active » Fixed

Discussed with sun and Gábor in IRC. We have a newborn project :)

http://drupal.org/project/entity_translation

Gábor Hojtsy’s picture

Yay, yay, and yay.

plach’s picture

good_man’s picture

I need a grep & sed search and replace (translation/entity_translation) now :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.