Find a consistent naming scheme for translation-related modules

In #1043198: Convert view modes to ConfigEntity we've decided that "Entity" is a fine word to expose in the UI, and that patch adds the entity_ui.module.

Not necessarily this issue, but could be: How about also renaming the module from translation_entity.module to entity_translation.module. I find the former, current version quite unintuitive.

I would be fine with translation.module (although I still find entity_translation.module clearer), but translation_entity.module sounds like this module provides an entity type, which is a translation, i.e. a 'translation entity', which, needless to say, it doesn't.

Keep in mind that we want to rename locale module as well and that deals with "software translation" or "user interface translation" as the UI calls it. Also we will need a contrib module to provide a configuration translation interface. So coming up with a good naming scheme instead of treating this as a case on its own would be important.

Repurposing per #5.

For the modules page, I think we're already trying to move away from the huge "Core" group, so I think we could get away with moving all this into a "Translation" group. That way they would naturally be grouped together.

So I still think:

entity_translation.module    => "Entity translation"
config_translation.module    => "Configuration translation"
interface_translation.module => "Interface translation"

would be the most natural.

"x translation" seems better to me than the "Translation of x" scheme but only if we are to group them together - if not, then we should go with "x translation". No matter what, the "Entity translation" should be "Content translation" (at least the UI-facing text if not the module as well).

Well the module should *definitely* be called entity_translation (or translation_entity) in code. The UI part I don't feel strongly about, but keep in mind that the Node entity's label is currently "Content"...

#1293304: Break up locale.module, but how? should have some prior discussion as well to serve as input.

This does not belong to the entity translation queue.

Putting on sprint. Would be good to have some decision here so we can start executing soon :) It would be useful to have good name proposals in place for usability testing. At least for the module list - even though we want to rename the whole modules :)

So looks like we will have 3 core modules related to language:

- language.module that handles base language functionality; this looks like is well named for everyone, no complaints posted above :)
- translation_entity.module to translate content entities (terms, users, etc.)
- locale.module to handle software translation (which includes default exported configuration which was part of the modules/core; but is mostly UI text that was actually in PHP code or twig templates or JS files; essentially this is to translate anything that came with the package from drupal.org in short)

We'll likely not have a dedicated config translation module in core (to provide translation UIs for config you created), that seems like will be in contrib. So the naming scheme we set up would ideally accommodate that as well, but not as a core module.

Anybody knows more about the grouping plans in core? Would there be groups so that contrib modules could add their modules into? Eg. a multilingual or language group in core that contribs can add modules to? From an end result point of view that sounds best for our goals. (It might not make the core/contrib separation clear on the UI, but not sure if making that distinction is more helpful than harmful).

Fix tag.

Tag for usability.

I agree that a Multilingual or something similar package would make sense, there is for example also #1255696: Needs docs update: Move field type modules into separate "Field type" package. Then we don't need to use "Translation of X" just to have those modules at the same place in the list.

It might not make the core/contrib separation clear on the UI, but not sure if making that distinction is more helpful than harmful.

Agreed, having a number of useful packages/groups sounds much more useful, just like we have those categories on admin/config.

My stance:

1. language.module is a good name. locale.module is a fine and almost industry standard module name. translation_entity.module should be renamed to translation.module, after the old translation.module has been removed (some tests are still relying on it).
2. AFAICS, the earlier suggestion of "Translation of X" as human-readable module labels is rooted in the idea that modules are sorted alphabetically on the Modules page, so they would appear next to each other and be easily discoverable. That idea already stops to work with Language module though, so I do not think we should pursue that idea further.
3. FWIW, I do think that it is fine for human-readable labels to be different from the internal/machine module names. The only audience that might get tripped up by that are developers, and they [we] ought to be able to deal with it. However, those cases should be rare, and if we do that, then the human-readable label should better be top-notch user-friendly — e.g., "Translation UI" (for locale.module) does not qualify there, since it is ambiguous in its meaning (Just the UI to translation API module?) and the label does not tell anything that "Locale" would not (Does the Average Joe know what "UI" means?).
4. For the fields related issue mentioned in #17, discussion actually turned out that a package/group does not work out, since some of the modules provide more than a field functionality and therefore discovery would be harmed for some users. This may not necessarily be the case for language-related modules, but we'd have to carefully double-check that first.
5. I strongly believe that no amount of module name/label trickery will be able to resolve the actual problem of the user interface, so I've created:
   #1868444: Introduce tags[] in module.info.yml file to categorize modules by provided functionality.

locale.module is a fine and almost industry standard module name.

Well, if you ask Google to define "locale" for you, this is what you get: A place where something happens or is set, or that has events associated with it. If you look at Wikipedia that defines locale in context of computing In computing, a locale is a set of parameters that defines the user's language, country and any special variant preferences that the user wants to see in their user interface. Usually a locale identifier consists of at least a language identifier and a region identifier..

As a matter of fact, Drupal's locale module does not deal with any of these things. All it does it relates English source strings for user interface (coming from .yml, .php, .module, .info, .js, .twig, etc. files) to translations in other languages, and automates their download and import on the site. It does not deal with country or variant preferences (currency, number formats, calendar & date formats, whatever).

It is true that locale is a well known industry name, it is also true it is well known for functionality NOT provided by the locale module (and mostly not provided in core at all). That is one of the great reasons we want to rename locale module. If there is everyever functionality that actually provides locale (and the site's country and date format settings currently both provided by system module are part of such feature set, while locale module's current functionality is not), then we would even have the namespace ready for it to be introduced.

For the fields related issue mentioned in #17, discussion actually turned out that a package/group does not work out, since some of the modules provide more than a field functionality and therefore discovery would be harmed for some users. This may not necessarily be the case for language-related modules, but we'd have to carefully double-check that first.

If the group is named "Language" or "Multilingual", it is hard to argue that those would not encompass the features of the modules involved (or that the modules would have other features - I don't know of any).

I totally agree with #19. I have a hardcoded str_replace('locale', 'interface_translation', $str); in my brain for exactly that reason. And because of that I also think renaming 'translation_entity' to just 'translation' would be too ambiguous. Even if we ultimately don't end up with an interface_translation.module (which I would find sad), there is almost certainly going to be a config_translation.module in contrib (which 80% of people who use "translation.module" would install), so at that point translation.module is already a WTF.

Really happy to see this :) The names have baffled me over the years.

1. We need to categorize these, for now the tool we have to do that is the module categorization. Making a Multilingual group for that reason, sounds awesome. I definitely want to break with the idea, we should have one "Core" group.

2. I think the goal for renaming should be to use more beginner friendly names, sadly multilingual has a lot of lingo that often does not make sense for those who are not totally into translations. Beginning site builders, turn to contrib and/or wikipedia to use the functionality hopefully by grouping and renaming we can solve this.

I'd like to end up somewhere around:

Language -> Language/Multilingual
Entity translation -> Content translation
Locale -> UI translation

Although I am sure we won't find labels that perfectly encompass the module and its functionality, we should use labels that will fit the 80% usecase of that module - whether technically it might not be 100% correct, it will steer people in the right direction and that's all we need. We can use the description to potentially address use cases outside that 80%.

For the sake of progress, we should set a side relabeling that we agree on - this way, we can have a more focused discussion.

Here are the changes proposed by Bojhan only applied to the info files so we can ponder:

Note that this made the multilingual modules show up under all other core modules.

I also shortened the Language module description and made it more user-friendly. It did not mention before that it would let you assign those languages to content, which is pretty critical functionality. However, with all the improvements to negotiation that is something we hopefully have a good default config and people should care much less, so no reason to scare people away with that lingo (we don't even use that lingo on the UI where detection and selection is configured).

Also qualified "entities" in translation entity module to "content entities", so it is friendlier but still technically correct. It could says "content" only however that would not be technically correct. I can imagine that would be suggested anyway, so bring it on :D

The internal names of the modules can be discussed as well if/once we have some agreement on how they should be exposed to the user.

On a sidenote "to be used on your website" is probably also very superfluous in the language module description.

Fix that and the Content Translation capitalization. The "you" in the language module description is also very un-core as well, not seeing that in any other module descriptions. The closest wording is "Allows users".

Looks good to me, if it's not a problem on the UX side I'd prefer "Interface translation" which would be more consistent with the Language API terminology (and visually more symmetric ;).

For the same reasons I'd go for:

• translation_content
• translation_interface
• (translation_config)

for the module namespaces.

@plach: I also discussed with @Bojhan I was not sure about "UI" vs. "interface", he pointed out "UI" appears twice in the module list in "Views UI" and "Fields UI". That might or might not validate this shortening.

The admin menu items is "User interface translation": we should aim for a bit of consistency here :)

Well, "UI translation" might in fact be more consistent with that vs. "Interface translation" :D Also, we can change the menu item labeling as well (eg. that to "Interface translation" if we believe that is better).

Yeah, that wasn't an argument to support my proposal, but whatever we choose should be reflected there, I guess ;)

About UI: it's true it's recurring but I, for one, associate a UI suffix to a module providing a front-end to an underlying API. Not sure whether this is an argument in favor or against "Interface translation" :)

+++ b/core/modules/language/language.info
@@ -1,6 +1,6 @@
 name = Language
-description = Lets you configure a number of languages to be used on your website and provides language negotiation functionality.
...
+description = Allows users to configure languages and apply them to content.

Since this module is key and central, I'd suggest this description:

"Adds language support."

I'd suggest to leave out the "apply to content" part, because that fails to manage user expectations. While it's true that Language module allows to assign a language to content, that's guaranteed to not be the functionality that >80% of users expect from a module description that states it.

(Also, dare I say that we should either drop that <10% functionality or move it into a separate module? ;) I can't think of an 80% use-case that couldn't use it from contrib, or possibly much rather, for which I'd use the multisite feature instead...)

+++ b/core/modules/locale/locale.info
@@ -1,6 +1,6 @@
-name = Locale
+name = UI translation
 description = Provides user interface translation to languages other than English.

I'd suggest this:

"Interface translation

Translates strings in the built-in user interface."

+++ b/core/modules/translation_entity/translation_entity.info
@@ -1,6 +1,6 @@
-name = Entity Translation
-description =  Allows entities to be translated into different languages.
+name = Content translation
+description =  Allows content entities to be translated into different languages.

I'd rather keep the existing, since I don't think there's any reason for why entity translation wouldn't work for non-content entities, too.

However, I'd rephrase it to be more active:

"Allows to translate entities into different languages."

Potentially also: s/different/other/

Perhaps even: d/different/

"different/other" doesn't really have a meaning in the multilingual space, I think. ;) "translate" already encompasses what that adjective tries to add.

EDIT: So I'd suggest to go with one of these:

A) "Allows to translate entities."
B) "Allows to translate entities into other languages."

I'd recommend A).

@sun:

1. I'd not say it is < 10% functionality to say this node is in German and that node is in French which is what "apply to content" wanted to mean there. It was supposed to designate that this is the module you need to apply language to content but not necessarily to translate it (which is the distinction between the language and content translation modules).

2. On "Translates strings", I'm not sure we every say "strings" elsewhere about this UI. That is a pretty technical term.

3. "Allows to translate entities into different languages." is better than previously where it said "allow entities", where it sounded like it allows entities to do things :D However, it removes "content" from the description making it more technical. Also less accurate even in its technicality, since config entities will not be translatable with this module (unless they use stored fields of course, which config entities do not do so far).

re: #32:

1) I know. :) But I also know that I have yet to find a user (as in: real word use-case) who actually thinks that this is useful on its own in any way and demands for the functionality to be kept available standalone, without having a need for actually translating content. The majority of users will get confused by the statement of "allows to apply language to content." Even I would be confused and would have to remember that it doesn't actually do what it claims to do. ;)

2) Good point on "strings" being too technical! :) That allows us to shorten it even further :)

"Translates the built-in user interface."

3) Long story short: If it is only about fields but not about entities, then the module should be renamed to field_translation. :P :) ...along with a label of "Field translation" and "Allows to translate fields." However, is that actually the case? @plach to the rescue? :)

:-)

I always thought we were going to be able to translate node->title in D8, but maybe I missed that being punted at some point.

Entities need to support it, namely by adding a data/properties table and with the new naming concept of EntityNG, everything is called field (not necessary a field.module field, which is I think going to be called dynamic field). See #1498674: Refactor node properties to multilingual, which is a critical task, postponed on the EntityNG conversion of nodes. Not having that would be an obvious regression to the existing translation.module and we couldn't really remove it from core.

So, technically, translation_entity.module in fact does "just" translate fields. But from its perspective, an entity is nothing more than a collection of fields and by translating fields, you can translate all there is about an entity.

What @Berdir said.

AAMOF I've never been in favor of the "Field translation" terminology because it describes how the module does its stuff instead of describing what it does. It would be like calling the "Views" module "UI-driven query builder".

As I already said elsewhere, my personal pov on the content vs entity debate is that the Entity Field API let's you attach data to entities (no matter whether dynamically or by hardcoding it). If you translate (pun not intended) "data" to "content" as a more user-friendly term, then you have that any entity can have content attached, which then you translate. Nodes are nothing more than basic content augmented with further content :)

Reality is that our "field data" may be content, metadata or a mixture of both, but I don't think we should expose these concepts at UI level. Config entities are no different in this sense.

Probably a technically correct term would be Multilingual data, if we were able to translate config entities with ET.
Edit: I'm not saying we can't, I'm saying I've no idea of which is our current ability to store ML configuration.

@Gábor Hojtsy, #26/@plach, #29: ...about the "Views UI" and "Fields UI" thing: How about we changed our policy/mentality and instead of naming the user-facing modules "[modulename] UI" we simply named them "[modulename]" or even better "[modulename] Manager" and had the respective API modules renamed to "[modulename] API"? So, in this case we'd have "Views Manager"/"Views API" and "Fields Manager"/"Fields API" instead?

BTW, I don't know what we'll finally settle for here as the module names, but we definitely need to #1868930: Ensure proper capitalization is used throughout the UI. So, if we decide to go with "Field translation"/"Entity translation", then they should be "Field Translation"/"Entity Translation" instead (capital "T" in "Translation").

@sun: I applaud your striving for simplicity, but I don't think there is a point in giving language module a description if all it says is "Add language support." Really? I mean we can simplify user module down to "Add user support." (It currently says "Manages the user registration and login system"). If we don't use the descriptions to elaborate a little on the module's functionality and just repeat the module name, then the description is just visual clutter and only there to fill in that table cell with something.

@klonos: thanks for the heads up on module name capitalisation standards changes. I must say I'm outright amazed by this change, but if that is the way it should be, then whatever :) On renaming other modules to other things, that is not related.

@sun: also re:

[...] I also know that I have yet to find a user (as in: real word use-case) who actually thinks that this is useful on its own in any way and demands for the functionality to be kept available standalone, without having a need for actually translating content. The majority of users will get confused by the statement of "allows to apply language to content." Even I would be confused and would have to remember that it doesn't actually do what it claims to do. ;)

I think its hard to argue that in this time of semantic markup and JSON-LD data exports, it is relevant that we have data on content as to what languages they are in (even if this data is not normally output on an HTML webpage). As-in if you ever created a German only site, I think you expected Drupal to be able to tell your nodes are in German. So that you are not bothered with translation features but if you ever want to translate them to other languages, they are already well set up. Also, the proximity of the language module and content translation modules would hopefully clearly highlight the separation and manage user expectations. Your argument would stand a better chance if we'd not do anything to group the modules together AFAIS.

Updates based on @klonos' feedback on proper name casing; takes @sun's proposal for locale module's name and description and tweaks language and entity translation. Also realized that as long as we have the node-copy module in core, we need to keep maintaining its placement and naming as well. Eg. with this proposal, it would be named the same as the field/entity translation module. Hah! (The legacy module can only be seen by those who upgraded from Drupal 7 and had the module enabled when upgrading, and once we fix node properties to be multilingual, we can work out the upgrade path there and remove that module).

Looks really good to me!

Minor, what about: "Allows users to translate entity content"?

@plach: depends on what entity content means; the module does not allow translation of config entities (aka *the content of config entities*). I think what you are getting at is "content attached to entities in fields", which I wanted to shorten in the "content entity" term that is I believe the official Drupal terminology for non-config entities.

Yes, this is what I meant, ET does not deal with config entities now. Not sure about the future...

Looks good to me.

I'd recommend to remove the package changes from this patch, and get the name/description changes in first, since those are 100% RTBC.

On the contrary, the package name change is highly controversial and I'd estimate a maximum chance of only ~40% for it to land. Although I proposed a similar change for field type modules in another issue myself, I always knew that it is architecturally wrong and (ab)using the package facility for something it wasn't intended nor designed for, and that the approach does not scale at all.

I'd therefore suggest to move that Core » Multilingual package name change proposal into a separate issue, which will ultimately compete with the change proposal in #1868444: Introduce tags[] in module.info.yml file to categorize modules by provided functionality., and we'll want to figure out which one of both to do for D8 then.

@sun: I discussed the grouping question with Bojhan and he supported breaking up the "Core" group finally. Also the group itself is a usability improvement to improve discoverability of the language modules. Tagging them and then requiring users to figure out those tags in a select list will not have a similar usability effect compared to visual grouping right away. Especially when contrib modules are involved which will drop into the same group. User heaven.

The point is that doing this package name change in core

1) will officially endorse the (ab)use of packages as a mechanism to group modules that are not in the same package. A 'package' property in metadata for software actually has a well-defined meaning. Drupal's interpretation comes relatively close to that, but has been muddied over time (primarily due to contrib). The modules could be understood to be in a package, if they were distributed together on their own. Unless I'm mistaken, the more correct technical way with regard to package definitions would be to define a 'subpackage', but of course we don't have any support for that.

2) will result in other core modules/components to consider to do the same, but as already mentioned before, for some modules it is not possible to use a single package name, because they actually need to be categorized into multiple groups. Consequently, having some core modules in dedicated groups, but some others not, leads to an inconsistent interface. Users will be confused, since they do not know in which group they have to search for, since the functionality they are seeking for may be contained in a dedicated group, some other dedicated group, or in the Core group (which inherently turns into a dumping ground for everything that cannot be classified with a single category, and thus starts to duplicate the second dumping ground of "Other" that exists already).

3) will in turn result in a user interface that is unusable, since it inherently means that there will be many more groups, which cannot be "un-grouped" or filtered/grouped differently, so the real world scenario for a user who's facing contributed and custom modules will look much worse than today already.

I think it would be great to get those label/description changes independently from the package name change.

I am really happy with these improvements, and going to mark it RTBC.

@sun I agree, that we need a better grouping pattern. However currently this is the pattern we have, and for the intended purpose here creating a Multilingual group works. We don't know yet if "tags" is the solution for this, in the time we decide if it is or not - this is a good interim improvement, we can usability test and gather more feedback on from other contributors. Given that its not a huge, code/UX change - I am personally fine with keeping this in. So I have marked it RTBC, and will wait on more feedback from committers on this.

There was one reference to the entity translation module in the dependency test. Fixing that was trivial. The depdency tests pass for me locally, so should pass. Back to RTBC with that.

RTBC +1

I think this is a good improvement.

I'm comfortable with the grouping/packaging, but we can certainly continue to discuss it.

Committed to 8.x. Thanks.

Follow-up bug report: #1871328: Modules in new Multilingual package are no longer tested by Module\EnableDisableTest

Another relatively minor followup (no regressions in functionality at all): #1879732: Language-related modules not listed on available updates page. I believe that is the only remaining followup issue to resolve for this change.