fields on terms are not translatable

also, the field values themselves are not translatable strings so std string translation does not apply either.

a few screenshots of the issue:

http://screencast.com/t/MkNPsykkqS7
http://screencast.com/t/2RXw0HBda
http://screencast.com/t/zmcWqGOCjU9
http://screencast.com/t/WGv4fVQOk
http://screencast.com/t/wABg6lDBXV

are you referring to vocabulary setting or disabling modules?

hmm.. perhaps you mean node translation vs field translation? our plan was to go with field translation but too many issues with this at the moment; the biggest of which is that many/most modules still don't integrate with the concept of field translation.

one major module we require is workbench; which actually doesn't work at all with field or node translation; but easier to fix for node translation. (views also isnt very i18n field aware). so, at the moment.. nodes which are set for workbench control use node translation; others are set as field translatable (although not sure if this will remain as still bugs with things like Title and EntityAPI).

hadn't realized it was not possible to mix/match these 2 methods and also don't see how it should impact fields on terms - other things under entity translation control seem to work fine; although there are clearly "bugs" between these 2 methods.. for instance field may be set to translatable even the the node type is set as not having translatable fields.

if this issue is due to interaction between these 2 methods i can likely disable entity translation until the rest of Drupal world catches up with this method (which i think is a better paradigm) - perhaps a note on project pages for these 2 projects stating they should not be combined would be good interim solution?

hmm.. interesting.. perhaps i have had this wrong.. i thought the entity trans module was the module adding the translate tabs.. and then from your post i assumed disabling taxonomy translate module would give me a different method to translate terms (and their fields); but oops.

after disabling taxonomy translate module i now get this as vocab edit screen: http://screencast.com/t/8Dozw1U5S5Xl

and no translate tab on the term so no visible method to translate the term at all.

so mostly just confused now. are you saying entity translate does not provide a mechanism to translate terms and that having it enabled simply breaks i18n method of translating terms (by breaking field translation).. so confused.. lol

got it. thanks.

pretty confusing that these both do the same thing and no indication which is being used.

thanks for your help.

most confusing part i guess is the vocab multilingual options section and having to state NO multilingual options for terms. likely entity translation should likely have a formalter to add something here (like a 5th option or at least a note)

hmm.. yea, this still seems busted to me: http://screencast.com/t/UcdOelSOE46

now, as far as i can tell, i do have the ability to translate the fields on the term; but now, not the term itself... almost sounds like the Title module is required. hope not.

wow.. quite the mess. so fields is part of core but no method to translate these for terms except to use entity translation which requires a module to replace the term field? at least for nodes we can still revert back to translated nodes.

i guess the idea of having entity translation simply merge its term field translate field form with i18n's form to translate the term and description wouldnt have made sense?

re: #12.. although, sadly.. Title doesn't actually work: #1586002: Entity language handling broken

so it would seem that there is no working solution for translating terms with fields.. :(

it does seem odd that i18n/et don't actually work together and have 1 single form with the term name and the added fields on the same translate page rather than override each other when they are trying to do 2 different things.

i would be interested in fixing this but hoping to first get some confirmation that there is no i18n/terms/fields solution in D7 at the present time before looking to solve the problem. also, even if Title did work; what is it expected to do. would the new name field "term" show up everywhere people would expect term values to show? such as select lists, page titles, views, etc?

if not; i think my solution would be to merge functionality of i18n localized terms with entity translation translate fields. seems like it should be simple enough to do and is guaranteed to work with existing taxonomy modules.

nope. doesn't work.

i grabbed latest devs of both et and entity api and disabled i18n_taxonomy (which isn't a great solution anyway as other modules i have list it as a dependency)

this is what i get:

- http://screencast.com/t/Y3jELbgab34
- http://screencast.com/t/NbNR2V02G
- http://screencast.com/t/EaGRCm53P
- after replace i get batch api run
- http://screencast.com/t/35gWGiR589Vf
- list still looks ok: http://screencast.com/t/1HBjJdS8Xh
- editing existing term: http://screencast.com/t/ykbVVvZyx5ji - Name field is empty
- adding a new term: http://screencast.com/t/ZUz3ChtVVAh leaves this in the list: http://screencast.com/t/pj5IStDJ

- also, if i add Name entry to existing term (that should have had value imported): http://screencast.com/t/gOlJ82OPEJmA - it does save the name field value i enter, but it doesn't show in the list: http://screencast.com/t/Jis7GjzP0, nor does it use these Name field values anywhere: http://screencast.com/t/rfJExnkuJsEY

module versions: http://screencast.com/t/M6sBKlXW8ya6

it is good to hear that you think if this did work that the new Name field value would be used everywhere. not so good to think i might have to disable i18n_taxonomy to get this to work as there are other modules that rely on this (multilingual forum for example). i am sure will be easier to debug Title to figure out what is busted but can't help but think this is still the wrong approach for doing this - would think integration between i18n-T and ET makes more sense that trying to use Title... but, maybe i am missing something here.

i'll look at debugging Title

just tried similar test on a fresh D7 install - same issues.

i do have i18n enabled; but very few other modules. will disable all of these now as next test (although disabling i18n is not a viable option)

disabled all i18n modules, most other modules except for a few core modules and a couple field modules, complete list is:

admin_menu
bartik
block
contextual
ctools
dblog
entity
entityreference
entity_translation
field
field_sql_storage
field_ui
file
filter
image
libraries
list
locale
masquerade
menu
module_filter
node
number
options
path
pathauto
php
realname
search
seven
standard
system
taxonomy
text
title
token
translation
update
user
variable

still busted. will start debugging Title.

hmm.. seems i didn't simplify my test site enough. I was thinking it was Title that was busted but it is actually ET. If i disable all modules related to translation (i18n/et) then Title does the right thing:

http://screencast.com/t/6irVT4HFhdC4

and i can now add a term Name and have it show on the manage terms page.

but as soon as i enable ET; even though the manage term page is still ok; i can no longer see the term name when i edit the term: http://screencast.com/t/RagcYUJJxD

although i can't not initially see the Title replaced value in the Name field after enabling ET, i can go to the blank translate tab for the term: http://screencast.com/t/4XcI3WP9 and edit the EN version (which was empty) and add the term over again. After this; it does now correctly show when i simply edit the term.. ughhh..

i can repeat for the FR term.

so eventually i can get what appears mostly correct from an admin view for all this by redoing things a few times; but in the end the values still aren't used correctly. term page's now have no title (they used the Title module title before enabling ET) and the term reference field added to a node still uses only the original term value in EN not the Title value, and doesn't change as site lang changes to FR.

this has all been with latest devs of ET and Title (and latest release of core) so thought i'd go back to latest releases (alphas) for the 2 modules. i think pretty much same bugs... and there are at least 3 or 4 separate bugs in this. i'll try debugging a bit more now that i know this is more than just Title causing the issue but a little confused as to how this can be so busted and no one else has come across this.

have a simple but messy work around.

- use i18n_taxonomy to do title/description properties as it always has
- use computed field to create a fake version of your term field with t() wrapped around it.

in other words.. if you have a field called Footer that you want on your term; then add this as usual and then add a non db storage field called field_translatable_footer with this code:

$footer = array_pop(field_get_items($entity_type, $entity, 'field_blogfooter'));
$entity_field[0]['value'] = t($footer['value']);  // guessing t() not required here

and likely more importantly this code for display value:

$display_output = t($entity_field_item['value']);

a little clumsy but seems like the only solution at the moment for translating fields on terms.