Currently the "language neutral" concept is used in two ways:
- to indicate the language of nodes which have not been explictly assigned a language;
- to indicate the language of fields which have not been explictly assigned a language;
In both cases the "language neutral" concept has the same meaning, but the actual values assigned are different: nodes use an empty string, fields a ISO639-2 language code (zxx) which means No linguistic content / Not applicable.
Having two different language codes to indicate the same language is both wrong and error prone, AAMOF Field API has to take into account this situation, subverting the usual dependency order which sees Node module depending on the Field module.
I'd suggest to refactor Node to make it use the standard language code.
Comments
Comment #1
plachThe current patch moves the
FIELD_LANGUAGE_NONEdefinition to bootstrap.inc, rename it to LANGUAGE_NONE and make Node use it instead of the empty string.Attached is also a "light" version of the patch which does not rename FIELD_LANGUAGE_NONE. You can use this one for reviews, as the real one is bloated by hundreds of braindead search/replace hunks.
We just need an upgrade path and then we should be ok.
Comment #2
plachComment #3
yched commentedMakes sense IMO, and +1 for a shorter constant :-).
Patch raises exceptions, though.
Comment #5
plachThis one provides the upgrade path and should fix tests. I removed
FIELD_LANGUAGE_NONErenaming, but I'll add it again as soon as I get an ok for the light version.@yched: ;)
Comment #7
plachObviously URL aliases must be fixed too.
Comment #8
plachDamZ reviewed #7 in IRC and asked for the Big One!
Comment #9
damien tournoud commentedI like it, and I hope the test bot will too.
Comment #10
dries commentedI'm OK with this but I do want to note that, with this patch, we start mixing ISO-639-1 (two character code) and ISO-639-2 (three character codes). That is probably not a crime, but might be somewhat unexpected.
Comment #11
plachRereolled #8 and added the following hunk as #624290: Wrong default comment language went in:
@Dries:
I'd prefer to go with a ISO-639-1 language code too, unfortunately there is nothing like
zxxin it.OTOH the w3c specification of language tags allows mixing 2 and 3 character codes, AAMOF only languages defined in the IANA registry are legal and "When languages have both an ISO 639-1 two-character code and a three-character code (assigned by ISO 639-2, ISO 639-3, or ISO 639-5), only the ISO 639-1 two-character code is defined in the IANA registry."
Hence the IANA registry actually mixes 2 and 3 language codes, as we are doing here for the lack of an appropriate 2 characters code.
Comment #14
plachrerolled
Comment #16
plachsystem updates count went ahead, meanwhile
Comment #17
plachComment #18
plachGreen. The patch to be committed is language_none-635094-16.patch (the big one), the other is just for reviewers' convenience.
Comment #19
dries commentedCommitted to CVS HEAD. Thanks.
Comment #21
anarchivist commentedActually, I'm a little concerned about this -
zxxin my opinion is not the proper code for this. See this FAQ entry on the Library of Congress's ISO 639-2 FAQ. By specifyingzxxas the code, Drupal will be saying that nodes don't have any linguistic content! While in some cases this might be true, it's a pretty safe assumption that most Drupal nodes everywhere contain some linguistic content.undwould probably be more correct.Comment #22
plachI didn't notice the
undcode, I agree that it would be more appropriate, and the replacement would be rather easy.Comment #23
pwolanin commentedThe 'und' code has been there all along in the spec - I think there are other issues where it was argued against. I don't really care, but seems like a bikeshed argument at this point.
Comment #24
damien tournoud commentedI haven't noticed 'und' either. Sounds like a good idea. I'm not aware of any discussions between zxx and und, Peter do you have specific pointers?
Comment #25
plachI'd like to read that discussion too. Meanwhile here's a patch that replaces
zxxwithund.Comment #26
plachThis does not concerns TF anymore.
Comment #27
plachthe patch
Comment #29
pwolanin commentedHmm, maybe I'm misremembering - all I can find is http://drupal.org/node/394728#comment-2303062 where I suggested 'und' would be better :)
Comment #30
plachCan't reproduce any error on install but I found a couple of tests using explicitly
'zxx'instead ofLANGUAGE_NONE.@pwolanin: I didn't read any particular argument against
'und'in that issue. It seems we can safely go on, right?Comment #31
pwolanin commented@plach - I will be annoyed to have to fix up Apache Solr module, but otherwise, 'und' seems fine to me.
Comment #32
dries commentedCommitted to CVS HEAD.
Comment #33
catchThis needs upgrade docs. I just cvs-upped and got notices everywhere. We don't do HEAD-HEAD upgrades yet, but it took me a good ten minutes to work out there was no typo for uid anywhere and find this issue, it's quite likely some modules other than ApacheSolr are depending on the old field structure too.
Comment #34
plach@catch: which should be the proper place to document this?
Comment #35
catchJust at http://drupal.org/update/modules/6/7
Comment #36
axyjo commentedhttp://drupal.org/update/modules/6/7#drupal_language_none
How's that?
Comment #37
catchLooks great.
Comment #39
Andrew Schulman commentedSee also #965300: Change LANGUAGE_NONE to LANGUAGE_NOT_SPECIFIED; add LANGUAGE_NOT_APPLICABLE and LANGUAGE_MULTIPLE.