Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.The initial setup of Translation module is very hard to figure out. Let's improve the UX.
These are the currently required steps:
- Add another language.
- Go to the module's configuration ("regional") and enable the entity types.
- Go to the field settings of desired fields and enable them for translation.
- Create an entity.
- You should see a "Translate" tab next to the "Edit" tab.
None of these actions are documented somewhere, but totally regardless of docs, I think we can improve the initial setup UX by embedding these actions as warning messages into the UI.
- Remove the automatically preset variable_set from hook_install() that enables translation for nodes.
- Use hook_page_build() to output a list of setup tasks. Not hook_init(), because that also runs for non-page requests.
- Use
variable_get('translation_installation_tasks', FALSE)as primary condition for code execution. Once installation tasks are completed, set the variable to 1. - Output a warning message (not status or error) to output a list of remaining installation tasks.
#1012054: Document how to make the "Translate" tab appear is closely related to this issue, but I didn't want to hi-jack that one.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | et-1030038-17.patch | 5.44 KB | plach |
| #6 | translation-HEAD.install-ux.6a.patch | 4.42 KB | sun |
| #3 | translation-HEAD.install-ux.3.patch | 4.51 KB | sun |
| #1 | translation-HEAD.install-ux.1.patch | 4.72 KB | sun |
Comments
Comment #1
sunInitial patch.
Comment #2
sunWe can also reverse it and set a negated
translation_installation_incomplete(or similar) variable in hook_install(), and delete that once the module has been configured. hook_uninstall() should still make sure that it is deleted though.Comment #3
sunIncorporates #2 and fixes array_filter WTF/insanity.
Comment #4
rfaysubscribe
Comment #5
sunLet's make sure to clarify this in code.
Comment #6
sunoopsie, fatal error. Fixed in attached patch.
Comment #7
plachThe patch looks good, but why don't we check also if at least one node type has translation support enabled?
Comment #8
sunHm. Nodes may not necessarily be enabled for translation...?
But in light of that, we could check whether at least one field has been enabled for translation.
Did I miss any other required steps?
Comment #9
plach@sun:
Well, IMO nodes will be by far the most common use case, we might at least issue a status/warning message after clearing the system variable to remind the user to configure multilingual settings for at least one node type. Perhaps we might even want to remove nodes from the entity configuration page and just make them configurable through their own multilingual settings.
Yes, we might check that at least one field is set to translatable.
Well, permissions must be setup properly. And, as I said above, nodes must have translation support enabled and need to have a language different from none for the translate tab to appear.
Comment #10
rfayComment #11
rfayTrying out #6 with a commerce product entity.
Did this:
0. Enable content translation of product at admin/config/regional/translation
1. Create a plain text field on the entity
2. Check field settings to make sure it's set to translatable
3. Create a new product entity at admin/commerce/products/add/product
There is no capability to set the language of the entity and no translate tab for the new product entity.
Comment #12
plach@rfay:
ATM there is no generalized support for entity language: entity types having an explicit language handling support it by overriding the
TranslationHandlerInterface::getLanguagemethod. About the translate tab: perhaps product entities need to specify their base path (see taxonomy terms intranslation_translation_info).Comment #13
sunLooks like it would be good idea to move the issue in #11 into a dedicated issue. Would also like to know more about that, but can't really make something out of #12 ;) In general, the slogan for D7 is: Entities are in, nodes are out.
Comment #14
plachTrying to explain myself: there are entities that have a language property and entities that don't. ATM this is not crucial for the entity translation process to work: node and comments have an associated language, node language can be explicitly set through the node form, while comment language is implicitly derived from the content language when the user posts it. The related translation handlers access the language property, the default translation handler instead return the default language. The main consequence of this is that entities not overriding the default behavior are always considered to be created in the default language, which becomes the source/original langauge for them, while for nodes and comments we can specify which is the original/source language.
Comment #15
sun@rfay catched another installation step detail in his blog post http://randyfay.com/node/88
- Language negotiation configuration; without that, the language switcher blocks do not appear.
Let's make this installation task list feature-complete. Most people are going to have no idea of translatable fields and how they work, and will try to give it a quick test drive to understand.
Comment #16
plachMoving to the Entity Translation queue. Read #902760: Change module name so it can work with Core translation for details.
Comment #17
plachHere is a revised patch introducing suggestions for optional tasks. There is no check for translatable fields as body is translatable by default.
Comment #18
donquixote CreditAttribution: donquixote commentedThere is one more step to consider:
Content created as "language neutral" does not get the "Translate" tab. So, you need to visit the edit form, and set the language.
I miss a configuration option that would make the language a required field..
[sidetrack]
I wonder if this is a desirable behavior.
I am working on the migration of a community site, where each piece of content - esp, forum posts and replies - could be set to be in a specific language, and then translated by other community members.
A typical situation would be someone writing a post in Urdu, someone else translating that to English, and then yet another person reads the translated post and replies in English.
(ok, the choice of language was entirely made-up)
Result: A node in Urdu, with a comment in English.
This is currently not possible, if the comment language is derived from the node language.
Whether this has to be solved by entity_translation.. dunno.
[/sidetrack]