Closed (duplicate)
Project:
Drupal core
Version:
8.0.x-dev
Component:
taxonomy.module
Priority:
Normal
Category:
Feature request
Assigned:
Issue tags:
Reporter:
Created:
18 Feb 2012 at 11:15 UTC
Updated:
29 Jul 2014 at 20:24 UTC
Jump to comment: Most recent file
Comments
Comment #1
csg commentedThis patch adds a language field to the schema, and adds the field to the db in the update hook.
Comment #2
gábor hojtsy'language' in Drupal 8 should be 'langcode' in schema.
Also the $language in the update function would better be $langcode_field or something like that.
I don't think we ever do this. It is not a bad idea per say, but we usually default to '' and then init to LANGUAGE_NONE in save functions (but we don't give a meaning to the empty langcode value).
Let's not modify an existing update function, create a new taxonomy_update_8001().
Speaks for itself :)
Comment #3
csg commentedThanks for the review! Here is the new patch.
Comment #4
csg commentedComment #5
pp commentedhmm... why is the end of the file at middle?
Comment #6
gábor hojtsy@pp: well, looks like it is being removed there. Looks good in that regard.
Comment #7
csg commentedThis patch also sets the langcode to LANGUAGE_NONE when saving a new term which doesn't have a langcode.
Comment #8
fubhy commentedThe indentation is not right here.
Other than that it looks okay.
Comment #9
fubhy commentedWe probably want to remove the $key_new = array() part there too.
Comment #10
csg commentedThanks! I updated the patch.
Comment #11
csg commentedI corrected the field name in the update hook.
Comment #12
kalman.hosszu commentedI checked the code and the tests run well, so I change the status to RTBC.
Comment #13
xjmIs it possible to add test coverage for this?
Comment #14
gábor hojtsy@xjm: right, that we don't have a UI for it yet should not stop us from adding tests to the API. Ie. saving a taxonomy term as default and one with a specific language and then loading them back in checking if that succeeded.
Comment #15
xjmCool, there's an API-only test class that should work for this. It's named
TaxonomyTermUnitTestcurrently (despite that it actually extends the web test class). (See also: #1446366: [meta] Multiple web test classes mislabeled as unit tests. simpletest ([Web|Unit|DrupalUnit]TestBase))Comment #16
gábor hojtsyAlso, as pointed out in #1444992: Add langcode property in file schema if the schema did have a langcode property, leave that alone (assume it is in the form we need) - ie. skip the update. To support people previously running modules that might have added that in D7 to support taxonomy translation.
Comment #17
effulgentsia commentedClarify which table the field is being added to.
Unnecessary comment.
s/language/language code/
I think this would be better earlier in the function, before the presave hooks are invoked on other modules.
6 days to next Drupal core point release.
Comment #18
effulgentsia commentedThis patch addresses #16 and #17. It also adds langcode to {taxonomy_vocabulary}, since vocabularies are also entities, according to taxonomy_entity_info().
I disagree with #14. I added the assertions in #1444992-22: Add langcode property in file schema because there was already a test for file_save() to add them to. However, none of our other entity types have low-level unit tests for saving via the API and verifying that each property got saved correctly. I don't think this is the issue in which to add such low-level unit tests. We may want to do so for all entity types, especially in relation to the Web Services initiative (where all of our entity CRUD needs to be fully decoupled from forms), but I don't think it's needed here. That does mean we don't have test coverage for now for this property, but I'm assuming after this lands, there will be a follow-up issue for moving node.module's UI for langcode to all entity forms, and we can incorporate functional tests there. In the meantime, this issue just lays the groundwork for that work. So, I'm removing the "Needs tests" tag, but please add it back if you disagree with me.
Comment #19
gábor hojtsy@effulgentsia: great improvements, thanks! On the unnecessary comment, honestly I was not aware of the initial property and ot made Dave Reid puzzled in the file langcode issue, so that is why it seemed logical IMHO. I agree it is not necessary if we assume people know about it :)
Any other concerns from people?
Comment #20
gábor hojtsyBtw we likely need upgrade tests, no? Even though the change itself is pretty darn simple.
Also, do we want to defalt to the site default language in the upgrade instead?
Comment #21
xjmAye, I'd agree that upgrade path tests are a really good idea any time there's a
hook_update_N()in a patch, really.Comment #22
gábor hojtsyAdding back Needs tests at least for the upgrade tests.
Comment #24
effulgentsia commentedMerging this into a combined issue in #1454538: Add langcode property to all entity types; for the user entity, distinguish entity language from user's language preference. Will address #20 in that patch.
Comment #25
gábor hojtsyRemoving outdated tags.