Posted by plach on July 29, 2009 at 12:27am
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | language system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
| Issue tags: | D8MI, i18n sprint, language-base, translatable fields |
Issue Summary
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.
Comments
#1
#2
The last submitted patch failed testing.
#3
subscribing
#4
fixed a simpletest
#5
slightly reworked patch
#6
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#7
@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 :).
#8
The last submitted patch failed testing.
#9
rerolled
#10
The last submitted patch failed testing.
#11
I forgot to fix my own tests :(
#12
- testbot seems to be happy...
- I like where this patch is going
- the admin interface is not optimal (but sufficient)
#13
The last submitted patch failed testing.
#14
#15
The last submitted patch failed testing.
#16
Tagging.
#17
Straight reroll.
#18
The last submitted patch failed testing.
#19
my own tests...
(sigh)
#20
The last submitted patch failed testing.
#21
head broke -- resetting status
#22
A couple of screenshots to help people understanding what's going on here.
#23
The last submitted patch failed testing.
#24
#25
#26
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?).
#27
.
#28
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.
#29
#30
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 :)
#31
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.
#32
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.
#33
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.
#34
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.
#35
Not working on this currently :)
#36
More lively discussion at #1314250: Refactor "enabled" bit on languages to be a set of bits.
#37
Tagging for base language system.