In Drupal, we aim to provide a generic language list, but in effect, people use languages for all kinds of things, and which languages from the general list are applicable to which operation are not possible to define.
Some examples:
1. Site wants to track English (US) and English (British) content separately. They don't want to have user interface translation for them (even if they have other languages, they want to have UI translations for). This means their list of languages for UI and content are largely overlapping but not equal.
2. Web application wants to offer its interface in various languages (think google search), but help pages and documentation on the web app will be available in a limited set of languages, and no intention to offer more. Language switchers in the documentation area (for content) would show less languages compared to the language switcher on the web app. Content language assignment should not show irrelevant languages.
3. A web site wants to expand into more languages, and while the new language pages are built out, they obviously don't want their language switcher links to show the soon to be added languages, so users are not confused that the content is not there yet, since its unpublished or permissions to be only seen by QA stuff at least.
To support these use cases, we'd basically need to refactor the "enabled" bit on languages to be a set of feature specific bits. Whether this language is enabled for UI translation (also very useful for #1266318: Make English a first class language where we are attempting a stop-gap solution for now), whether this language is exposed in language switchers, content language assignment, etc.
Related Issues
- #1266318: Make English a first class language
- #533924: Allow different language types to be enabled separately
- #198355: how to disable 'language neutral' option for creating new pages?
- #1539072: Support for disabled languages broken, drop it
- #258785: Provide more flexible settings for initial language on content types
- #1810386: Create workflow to setup multilingual for entity types, bundles and fields
- #1993928: Language of parts: Introduce a language toolbar button
- #2041115: Extend list of languages with all languages of ICU
Comments
Comment #1
Bojhan CreditAttribution: Bojhan commentedWhat is the 80% usecase? I dont really get the question.
Comment #2
Jose Reyero CreditAttribution: Jose Reyero commentedI think:
- Get rid of 'enabled' property
- Provide a way to configure different language lists (interface, content, field_xx ....)
Then, a language will be 'enabled' if it belongs to any of the existing language lists. And we just need to make that difference on the languages configuration pages so you know when you are editing a language that is currently being used for anything.
Comment #3
Gábor Hojtsy@Bojhan: the 80% use case is probably:
For site 1 above (tracking different versions of English content):
For site 2 above (content in English, UI in various languages):
For site 3 above (German content being phased in, note even more type of language list):
Now we only have one set of checkboxes so we cannot do this separation. In #1266318: Make English a first class language we arrived that we do need to expose a special checkbox to cover the "Enabled for UI translation" case separately for English. It would be ideal to generalize this eventually. Did this help?
Comment #4
plachI agree with Jose that this could be the right way to address the issue, but I have no idea of how the UI could look like. Marking #533924: Allow different language types to be enabled separately as duplicate of this one since the discussion here is more active.
Comment #5
Gábor HojtsyYes, technically it does not sound too advanced, the UI is in question, that is why I looped in Bojhan right away :) Sorry I did not find/remember the other issue...
Comment #6
Gábor HojtsyAlso count in that (IMHO) we want to provide a way for people to disable the "Language neutral" option for things. It can be pretty useful and pretty distracting at the same time. So we need a place to put enabled checkboxes for types of language use vs. the Language neutral language as well. @Bojhan: any opinions?
Comment #7
Gábor HojtsyTagging for base language system.
Comment #8
Gábor HojtsyThere are many people at #198355: how to disable 'language neutral' option for creating new pages? who want the functionality to disable language neutral for nodes.
Comment #9
Gábor HojtsyRetitle for the user problem, regardless of how we solve it internally.
Comment #10
andypostThis related #1539072: Support for disabled languages broken, drop it
If we drop support for disabled languages so this issue makes no sense
I think we should have 2 options/flags:
- enabled (should be dropped according #1539072: Support for disabled languages broken, drop it)
- published (language could be visible to visitors)
Comment #11
Gábor HojtsyI think this definitely makes sense as a usability tweak, some people don't want to see "Language neutral" in their node assignments (for certain node types) for example, because it does not make sense in their setup. It might end up as a contrib feature though.
Comment #12
andypostSo let's continue with this issue as #258785: Provide more flexible settings for initial language on content types
For each entity we need to implement a special settings a-la node does
Comment #13
Gábor HojtsyTagging for usability, since this came up when reviewing #258785: Provide more flexible settings for initial language on content types.
Comment #14
Gábor HojtsyComment #15
Gábor HojtsyComment #16
andypostWe could proceed with following
1) use enabled bits for each of language types
2) use settings per entity type like nodes does after commited #258785: Provide more flexible settings for initial language on content types
Comment #17
Gábor Hojtsy@andypost, we did #258785: Provide more flexible settings for initial language on content types with generalization in mind for more entity types, such as taxonomy terms too. Now we need to generalize the setting, but questions like how do we store the value regardless of entity/bundle were gaps that made us think about nodes first, because that in itself was hard. The "which language is applicable" can in fact deal with the same problem. If you have feeds feed entities, those would likely be saved as "language unspecified" if the feed is multilingual and you don't have a tool that identifies language on the fly for text. So other entity types need bundle level support as well possibly. Which means ideally we'd implement a system that can store these settings generally and apply them generally let along provide a sane UI.
Comment #18
andypost@Gábor Hojtsy: You talk about entity languages but whats about UI?
I'd like talk from CMI perspective about storage for this settings.
We have language_types_info() that cares about language definition and we could extend this by providing some kind of #access key.
OTOH #258785 stores data in variable, in CMI conversion this part is curious because it should be a kind of state inside a node-type definition but lives orphaned
variable_get('node_type_language_default_' . $type->type, 'site_default')
Also we could implement a db-table with fixed fields for your example in #3
Comment #19
Gábor HojtsyYes, the CMI conversion should take care of figuring out where do node related settings not necessarily directly provided by node module go (such as the translation setting). We did move the code on language assignment to node module but not the setting to the content type table, since CMI conversion is going on anyway.
Comment #20
Bojhan CreditAttribution: Bojhan commentedNo idea what to review.
Comment #21
Gábor HojtsyNote that this might be able to integrate into the UI framework set up in #1810386: Create workflow to setup multilingual for entity types, bundles and fields, where we have one screen to configure per entity type/bundle configuration for languages. The set of allowed languages for each can be part of the config, although admittedly under some kind of advanced settings container I think.
Comment #22
YesCT CreditAttribution: YesCT commentedany new thoughts on approach here, based on what's been done so far in other issues?
Comment #23
Hanno CreditAttribution: Hanno commentedBump from #1993928: Language of parts: Introduce a language toolbar button
Another usecase: accessibility demands language tagging in content (paragraph and sentence level), we should be able to provide a short list of languages (for example for a university: Dutch, English, French, German, Latin).
CKeditor will in the next release provide a language button for this. For this we need to integrate a configurable list of languages.
Comment #24
Mark_L6n CreditAttribution: Mark_L6n commentedRe: #23, WCAG 2.0 'Language of Parts' seems to present a slightly different issue than discussed here.
As I understand it, the issue here is to determine (in advance) which set of languages is enabled for which Drupal parts (admin, nodes, menus, taxonomy, etc. ?).
The issue for WCAG 2.0 'Language of Parts' seems to be mainly for a content author (at time of writing) to use and mark any language in a piece of content. Citing their example:
In the sentence, "He maintained that the DDR (German Democratic Republic) was just a 'Treppenwitz der Weltgeschichte'," the German phrase 'Treppenwitz der Weltgeschichte' is marked as German.
This phrase should be able to be marked as German whether or not Drupal nodes are enabled for German, and tags for all languages should be available for authors. (Although a short list of languages commonly used on the site could help speed this up.)
Comment #25
Gábor HojtsyWell, Drupal already lets you configure a set of languages, so you'll not get all languages on earth when you enter content. This issue is about filtering that further down as appropriate. It would be all site configuration level, not enforced by Drupal installation in general, so I don't consider that related to language of parts in general.
Comment #26
mgiffordAlthough the content author definitely needs to have access to selecting languages for the Language of Parts criterion and it's great that CKEditor is going to help facilitate this. However, the output from #3 should be tagged properly such that they include the
lang="zh-Hans"
or what have you that is related to the chosen language for each UI, nodes, files, etc..The W3C defines it reasonably clearly, but are based on a simpler example.
Comment #27
PanchoJust some considerations regarding the Language of Parts functionality:
I agree that for this functionality we need all languages be available to every user, no matter what languages exist on the system and no matter what an admin decided to enable or disable.
This should basically be independent even from the Language module, though not even our current standard languages list would be complete enough. We'd need to support all languages that have a language code. Latin was a good example.
So we'd need the standard languages list to be vastly extended. For installation we'd probably want to filter just the languages that have an interface translation. But at a later point, it should be possible to choose from all languages with language codes, be it Latin or Ancient Greek or Aramaeic. Be it just so the can be added to a custom shortlist of the most important citation languages.
Actually this aspect applies just as well to the translation of whole entities. It should be slightly easier and fool-proof to add any language on admin/config/regional/language.
We might also want to revisit the decision to have a Language module separate from the core library in core/lib/Drupal/Core/Language. Not much would be left in the module, if we move large parts of the language administration to the core library.
However, IMHO we should do that anyway. At least in the UI, it currently seems impossible to define a default language other than English without having Language module enabled. And the negotiation part is anyway only necessary with Content translation and/or Interface translation being enabled, so shouldn't be exposed by Language module either, if I'm getting this right.
If you could point me to an existing discussion, that would be awesome. Otherwise I might open a new issue for that.
Comment #28
Hanno CreditAttribution: Hanno commentedIf we want to have a language list with all languags, we could use the list available in the Intl component of Symfony (http://symfony.com/doc/current/components/intl.html). It uses the language list of ICU (used in Android, iOS etc). These are the languages you will get:
http://source.icu-project.org/repos/icu/icu/tags/release-50-1-2/source/d...
That include almost any language (including Aramaic, Ancient Greek and Latin).
Comment #29
Gábor HojtsyHow is this related to this issue?
Comment #30
Hanno CreditAttribution: Hanno commentedWell @Pancho considered to include all languages in Drupal to facilitate content tagging. But extending the language list and having a generic language picker should be another issue as this issue is about filtering the language list for specific uses.
It will mean that adding a language at admin/config/regional/language/add will give that complete list instead of the drop down we have now.
EDIT: added as an issue #2041115: Extend list of languages with all languages of ICU
Comment #31
PanchoWell, it is actually more closely related because the "language of parts" shortlist would be just another core use of the filter/configure/order functionality this issue here is about. With some special requirements, though, so I'm giving details.
Comment #32
Gábor HojtsyThat direction sounds possible in Drupal 9, if you'd like to target that, feel free to bump the version.
Comment #32.0
YesCT CreditAttribution: YesCT commentedadded related issues list.
Comment #33
Gábor HojtsyThis came up at Drupalaton 2014. Solving the whole issue is way too big which is why this never went anywhere. The block is an easy sub-problem though, and got @Janoka going on that at #2318429: Language condition / block language visibility includes useless options. Probably the rest is Drupal 9 or for later point releases.