I recently needed support for translations in Views with the term_fields module. Rather than hacking the module, I created a new one to override the original views handlers and add a hook_locale_refresh that exposes term fields to i18n. It doesn't do anything to standard taxonomy pages, as I only needed it to work with Views. Thought I would share it in case anyone else needs the same functionality. I don't have CVS access and I'm really not sure if this module should exist, or if the term_fields module should be patched to include something like it, but here it is for the community to decide. :)

CommentFileSizeAuthor
i18nterm_fields.tgz3.33 KBJohn Carbone

Comments

b-prod’s picture

b-prod commented
Version: 6.x-1.9 » 6.x-1.x-dev
Status: Active » Needs review

Your post sounds bizarre to me, but I will have a look soon on your handler. Actually I cannot figure exactly what you are speaking about, but after reading your code it may be clearer...
Thanks for your help.

John Carbone’s picture

John Carbone commented

In a nutshell, I needed to be able to translate term fields when used in Views. My module exposes term fields to i18n, allowing the text to be translated in the "translate interface" (provided by the locale module). Then it overrides the term_fields Views handlers to output the translated version. :)

rar9’s picture

rar9 commented

@John
Do I install this just as a normal module in order for it to work?

b-prod’s picture

b-prod commented

The files in the archive are supposed to be a module apart from term_fields, so you have to install it normally.
The integration into term_fields will probably be done some days, but not in the very next weeks.

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
commented
Status: Needs review » Needs work

Yes, let's get this integrated into Term Fields instead of having a separate module.

John Carbone’s picture

John Carbone commented

Very cool glad to hear it's being merged. Sorry I haven't checked this issue in a while. @B-Prod: Do you have any interest in a patch or would you rather integrate it yourself?

b-prod’s picture

b-prod commented

@John Carbone: yes I would prefer a patch against the DEV version, because I have very few time now for maintaining the module, so any help is really appreciated.
Thanks a lot.

John Carbone’s picture

John Carbone commented

OK cool, I'll try to set aside some time to make a patch for your DEV version.

b-prod’s picture

b-prod commented

Thanks for your help!

b-prod’s picture

b-prod commented
Version: 6.x-1.x-dev » 6.x-2.x-dev

User defined strings translation still need to be translatable, using i18nstring.
Some work has began for 'choice' widget, but need to be ported to all the remaining code.

Thomas_Zahreddin’s picture

Thomas_Zahreddin commented

there are two things to keep apart:

translation of strings in the user interface (UI) and translation of taxonomy terms and additional fields.
e.g.
'description' => 'This widget handles only integers.'

is not found for version 6.x-2.1

http://localize.drupal.org/translate/languages/de/translate?project=term...

use
'description' => t('This widget handles only integers.')
see http://api.drupal.org/api/drupal/includes%21bootstrap.inc/function/t

( in the moment i don't know if i use this module, so i don't provide a patch).

Content a user or administrator enters is handled by the module i18n_strings.

b-prod’s picture

b-prod commented

The i18n_strings support only concerns the name of field labels and other things that are created by users. And for those the support is not full and need to be improved. The current issue talks about that.

If there is some parts of code where I forgot to use the t() function, it is a bug, so you are welcome to provide a patch against such omissions, in a separate issue, or tell me exactly (file and line number) where I missed that.