While designing #367595: Translatable fields we agreed that we would need to distinguish between UI language and content language: the first one would allow a user to choose in which language display the site interface textual elements, the second one would be associated to content; the two types might be partially or even totally unrelated as one might want to enable more content languages than UI ones or viceversa.

The current patch slightly modifies the language configuration page to enable the admin to choose which type the language has; this setting is recorded in an additional column of the languages table. An upgrade path is provided.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

plach’s picture

Status: Active » Needs review
FileSize
17.67 KB

Status: Needs review » Needs work

The last submitted patch failed testing.

sun’s picture

plach’s picture

Status: Needs work » Needs review
Issue tags: +translatable fields
FileSize
18.34 KB

fixed a simpletest

plach’s picture

slightly reworked patch

alexanderpas’s picture

looking nice, yet tests to actually test the different added options seem to be missing, as the only thing being tested seems to be LANGUAGE_TYPE_ANY

plach’s picture

@alexanderpas: thanks for the review, this patch was created as part of a proof of concept work so initially I did not provide any specific test. In the current one the new functionalities have their own tests (I discovered a bug thanks to them :).

Status: Needs review » Needs work

The last submitted patch failed testing.

plach’s picture

Status: Needs work » Needs review
FileSize
21.44 KB

rerolled

Status: Needs review » Needs work

The last submitted patch failed testing.

plach’s picture

Status: Needs work » Needs review
FileSize
21.45 KB

I forgot to fix my own tests :(

alexanderpas’s picture

- testbot seems to be happy...
- I like where this patch is going
- the admin interface is not optimal (but sufficient)

Status: Needs review » Needs work

The last submitted patch failed testing.

sun.core’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch failed testing.

sun’s picture

Issue tags: +i18n sprint

Tagging.

plach’s picture

Status: Needs work » Needs review
FileSize
22.87 KB

Straight reroll.

Status: Needs review » Needs work

The last submitted patch failed testing.

plach’s picture

Status: Needs work » Needs review
FileSize
23.36 KB

my own tests...
(sigh)

Status: Needs review » Needs work

The last submitted patch failed testing.

alexanderpas’s picture

Status: Needs work » Needs review

head broke -- resetting status

plach’s picture

A couple of screenshots to help people understanding what's going on here.

Status: Needs review » Needs work

The last submitted patch failed testing.

plach’s picture

Version: 7.x-dev » 8.x-dev
Status: Needs work » Postponed
plach’s picture

Title: Distinguish between UI language and content language » Allow different language types to be enabled separately
Gábor Hojtsy’s picture

Status: Postponed » Needs work

How do you imagine other language types would work with this?

(Also IMHO moving a feature request to D8 is in itself postponing from Drupal 7, so no need to set to postponed, right?).

sun’s picture

Issue tags: +D8MI

.

plach’s picture

Issue tags: -D8MI

How do you imagine other language types would work with this?

I ain't sure this feature request still makes sense, I postponed this issue after the language negotiation revamp to see if this was still needed or useful. If we want to go on this way, I'd simply change the radios in a multiple checkbox selection listing all the available (configurable?) language types.

plach’s picture

Issue tags: +D8MI
Gábor Hojtsy’s picture

I think it could make sense to for example select languages only used for administration, which should not show up in language selectors. Probably not a 80% use case :)

plach’s picture

Are you thinking about introducing an admin language type? It might be tricky, I'd just go with smart language detection methods (see the second example in http://drupal.org/update/modules/6/7#language_negotiation), after all we are setting UI language here not else.

Gábor Hojtsy’s picture

Well, both of your suggestions at #322995: Provide a distinct administration user interface language option has side effects on the front end behavior of the site to support setting up a consistent admin language and even then required admin interaction, so I'm thinking that a separate list could be useful. I'm not sure the admin (usability) complexity is worth it.

plach’s picture

I agree that they are not ideal, I just meant that we can already achieve something similar with what we have in D7 core. IMO the best approach would be to have an admin language detection method that checks if the current page is an admin page and return a configured value or FALSE otherwise.

plach’s picture

Unless perhaps we want to make admin language type non configurable, so it won't appear in the configuration page. But I think that page needs some usability improvement anyway.

plach’s picture

Assigned: plach » Unassigned

Not working on this currently :)

plach’s picture

Status: Needs work » Closed (duplicate)
Gábor Hojtsy’s picture

Issue tags: +language-base

Tagging for base language system.