Internationalization allows to create translatable vocabularies and to translate terms. Where i18n is available, i think that only current language vocabularies terms should be displayed.

Here an example from the current version: i have 1 vocabulary with two terms "futari" (Italian and English). When filter is applied, the two definitions are displayed in the first two occurrences of the term. If i18n module is available, and when that term is translatable, it should be displayed only the current language version (using i18n_get_lang()).

I try with:

	if(!module_exists('i18n')){
		$result = db_query("SELECT t.name, t.description, t.tid, COUNT(tn.nid) as nodes FROM {term_data} t LEFT JOIN {term_node} tn USING(tid) WHERE t.vid=%d GROUP BY t.tid, t.name, t.description ORDER BY LENGTH(t.name) DESC", $vid);
	}
	else{
	 # get only current language terms if i18n module is available
		$result = db_query('SELECT t.name, t.description, t.tid, COUNT(tn.nid) as nodes FROM {term_data} t LEFT JOIN {term_node} tn USING(tid) WHERE t.vid=%d AND t.language="%s" GROUP BY t.tid, t.name, t.description ORDER BY LENGTH(t.name) DESC', $vid,i18n_get_lang());
	}

on _glossary_get_terms(), but it seems that cache display only English or Italian terms. Maybe a cache problem? Wrong inserted code? Any idea to make it works?

I have the same problem on the glossary page, but this time only first element appears. In this case, if the i18n module is enabled only current language terms should be displayed.

Combining taxonomy terms translation by i18n and language-based selection by glossary can lead to fully translatable glossaries.

CommentFileSizeAuthor
#5 glossary_i18n.patch4.75 KBnancydru
#3 glossary_i18n.patch3.28 KBnancydru

Comments

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

If I remember correctly from previous brushes with i18n, using a db_rewrite_sql would take care of this. I'll have to do some research because I am English-only and really don't understand all of this. I've opened a support request on i18n: http://drupal.org/node/233817

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented
Assigned: Unassigned » nancydru
Status: Active » Postponed (maintainer needs more info)

In _glossary_get_terms, could you try changing the query to this, please:

      $result = db_query(db_rewrite_sql('SELECT t.name, t.description, t.tid, COUNT(tn.nid) as nodes FROM {term_data} t LEFT JOIN {term_node} tn USING(tid) WHERE t.vid=%d GROUP BY t.tid, t.name, t.description ORDER BY LENGTH(t.name) DESC'), $vid);
nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented
StatusFileSize
new glossary_i18n.patch3.28 KB

Actually, here's a more complete patch that changes all the queries that I think probably need the db_rewrite_sql. It should also get the glossary overview page, which might be the first good test. And, yes, any time you're trying to check out something like this, it is best to clear the cache frequently, but definitely before testing this patch.

Please let me know what, if anything, happens.

chirale’s picture

chirale commented
Status: Postponed (maintainer needs more info) » Needs work

Hi Nancy, thanks for your patch.

I try it but I get this SQL error:

user warning: Unknown column 'n.nid' in 'on clause' query: SELECT v.vid, v.name FROM drp_vocabulary v LEFT JOIN drp_i18n_node i18n ON n.nid = i18n.nid WHERE (i18n.language ='it' OR i18n.language ='' OR i18n.language IS NULL) ORDER BY v.name in /my/path/to/cms/includes/database.mysql.inc on line 172.

It seems that "n" alias is somehow misplaced. I've tried to change some "n" alias occurrences but it seems a persistent problem. Any idea? Thanks.

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented
StatusFileSize
new glossary_i18n.patch4.75 KB

Okay, it would be nice if I would learn to read. The APIs for "db_rewrite_sql" specify that I should use a primary table name. So let's try this version of the patch. BTW, you get a bonus sneak preview of the "abbr" feature.

The API doesn't mention "term_node" so I'm not sure what to do with those queries, but they do also hit "node" so they may work correctly.

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented
Status: Needs work » Needs review

forgot the status

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented
Status: Needs review » Fixed

Fix committed to -dev versions.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

AaronCollier’s picture

AaronCollier commented
Version: 5.x-2.1 » 6.x-1.x-dev
Category: feature » bug
Status: Closed (fixed) » Active

I am currently not getting i8n support. I have terms that exist in two languages, English and Czech. I have connected the terms with the translate option of the taxonomy. But I only see the English option even when the page's language is set to Czech. Terms that are only in Czech appear in Czech, but terms in both appear in English. It would be nice to be able to see only Czech things.

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented
Title: i18n support » i18n support in 6.x

I would prefer that you had opened a new issue rather than reopening one that was fixed and closed.

Since I speak only English and don't have i18n, the fix for this is going to have to largely come from the user community, just as it did before. I know of other problems in this area that are still pointing back at i18n itself.

AaronCollier’s picture

AaronCollier commented
Title: i18n support in 6.x » i18n support
Version: 6.x-1.x-dev » 5.x-2.1
Category: bug » feature
Status: Active » Closed (fixed)

Sorry. I thought it was better form to build off of older patches. I'll open another issue.

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

Thank you. What I would prefer to see in a case like this is that a new issue get opened and reference the old one. If I think it is better to reopen the old one, then I can do so and mark the new one as a duplicate. Just one of the quirks of Drupal's issue tracking system.