Multilanguage support (at least for 6.x)

Are there any additional modules required for this level of
Internationalization in Drupal 6?

Also can you post patches using the Drupal standards:

cvs diff -up original.php > filename.patch
or
diff -up original.php new.php > filename.patch

I'm really busy with my day job at the moment. In the meantime
could you repost your patch using the Drupal standards?

cvs diff -up original.php > filename.patch
or
diff -up original.php new.php > filename.patch

It makes it a lot easier to work with

This is definitely a needed feature. Patch looks generally good.

Needs some code style cleanup--indent issues (tabs used instead of spaces).

Looks like the update missed changing the schema to add the new field.

I'll do the style cleanup, and take care of the schema issues as well.

Look out for a re-roll...

Hailu

Ok I've taken some time to start working on this and I have
a few comments on the patch and some issues that we need
to figure out.

FIrst off for the .install file, the changes to the table need to
be added to the wordfilter_schema() function as well as added
in as a hook_update_N function. Second the hook_update_N
must use the schema API to add the field. The version you had
was MySQL specific. I use PostgreSQL so that would be a problem :)
I've made those changes already.

Now the for module itself, we have a rather significant problem that
we have to figure out. Filtering on node/comment titles/subjects is not
a problem as we can do the filtering via hook_nodeapi and hook_comment
calls as in the module currently. Because we have access to the node or
comment object at that point we can pass in the language, if any, for the node
(or node that the comment is posted on) to the wordfilter filter.

However when we run the wordfilter filter on the node or comment body
this is done using the Drupal filter mechanism and so nodes and comments
are checked via check_markup during the node's hook_nodeapi 'prepare'
operation and during the comment's theme_comment_view function (or
other theme_comment_view theme override function). When check_markup
is called it only has the text to check and not other other information such
as the node or comment object.

So this means that when the wordfilter filter function wordfilter_filter_process()
is called we have no node context with which to extract the language setting
if any for that node. In the simplistic case where we are viewing a node we
might be able to test for arg(0) == 'node' and arg(1) is a number but that
won't help when we are viewing a list of teasers such as could be the case if
you are using Views and pulling a list of the latest 10 nodes on your site.

The alternative is to change the design of the module and do body/teaser filtering
in hook_nodeapi & hook_comment but the downside there is that you lose the
filter caching that you have via check_markup.

I'm open to suggestions of how we can handle this problem. maybe there's something
I'm missing here but I think that currently handling filtering via Drupal filters and
making use of node language settings is harder than the patch suggests....

I've posted a patch for D7 to add a $language argument to hook_filter(): #319788: Pass language information to filters. Reviews would be great.

For 6, the best we can do may be

$node = menu_get_object();

// We're viewing a node. If it has a language, apply its language's filter plus the global one.
if ($node && $node->language) {

}
// We don't know the context, so apply filters for all languages.
else {

}

The core patch went in. I think we shd use the temporary approach I suggested in #17 for D6 and then have a fullter solution built on the core change for D7.

I've worked on improving the patch.

Added code similar to #17, to make it get language in context. However I'm getting a WSOD when viewing a node. On listings (e.g. /node), only node titles get translated. So there is a problem on on the filter. I'm investigating.

Also, fixed code styling issues and added some checks so it don't cause fatal error if locale module is disabled.

Assigning to myself.

Updated patch.

I did some basic testing and it seems to be working.

I'm getting WSOD when i try to view a node using the patch from #21.

The corresponding entry from my error.log is "[Wed Nov 26 17:52:13 2008] [notice] child pid 9931 exit signal Segmentation fault (11)
"

#21 were you testing with filtering on node/comment titles enabled also? menu_get_object() basically ends up dong a node_load to return the node object. If you are filtering titles, then wordfilter_filter_process is called on the hook_nodeapi() load operation which leads to menu_get_object() again which does a node_load which invokes hook_nodeapi() and so on and so forth. I think perhaps that's what #22 was running into.

Changing to hook_nodeapi() $op = 'view', instead of 'load' fixes the issue. It's also now inline with hook_comment() implementation.

Is there any drawbacks from this change?

Changing to hook_nodeapi() $op = 'view' makes it don't work on node titles in full nodes.

So I tried a different approach with _wordfilter_list() accepting a object explicitly when one exists.

Here's a quick patch with my implementation. It varies somewhat from recidive's work most recently in #25 as I had already been working on the implementation up to the point the patches appeared here. However the basic elements of that patch as first posted in #20 are here.

This patch includes some other changes that haven't been committed yet mostly in documentation text and such. I'll commit those first separate from the multilanguage stuff here but for now I just wanted to have recidive and any other interested parties take a look.

subscribing to this, will do a proper review later on.

here's an updated patch without the changes to documentation and help text (already committed now).

re-rolled once again after porting another change in the d5 branch to d6.

I've got a window coming up at the end of the month where I'll be working on my modules...If recidive or anyone else can try out the latest patch please let me know the results.

anyone able to review #29? My window for pushing out a release with this patch is closing as I am relocating from China back to the US in a couple weeks...

subscribing - hoping to review this week.

Re-rolled patch with a few coding style changes, and also removed t() calls from the message strings passed to watchdog().

Overall the patch looks good and when viewing nodes with an associated language, the correct word replacement is done. However if viewing a "language neutral" node, then all language filters are applied. I'm not sure this is the desired behaviour. Here are the steps I did when testing:

• I enabled three languages on my site, English, French and German.
• I created a standalone word filter for the word 'foo' in both French ('foofr') and English ('fooen'), but none for German.
• I also added a word filter for 'all languages' ('foo' -> 'foobar').
• I created 3 nodes containing the word 'foo', one in each of the three languages.
• I created another node, again containing the word 'foo' and made it a "language neutral" node.

The correct replacement was done for French and English nodes. In the German node, the word was correctly replaced with the fallback 'all languages' replacement word. However, in the language neutral node, the French word replacement was done. I presume this is because it was the first word filter I set up. I think the correct behaviour would be to apply the "all languages" filter first for language neutral nodes. If no "all languages" filter is found, but there is a language specific one, then either apply that language specific filter, or perhaps it might be better not to apply language specific filters at all in this scenario.

Cheers,
Stella

Ok I added a query sort condition which should resolve the scenario mentioned in #33. Also folded in the other coding changes in #33.

hi ..i think you can use the module "Localizer" for multi language support..
Regards

#36: Localizer has been abandoned and only worked in D5 and also doesn't help with this. :)

Have there been any updates on this issue? We are willing to help out with this if any help is needed.

-Daniel

Well I've been reluctant to spend too much time on this as there were no perfect solutions. The feature in question has been added to core for D7 in the filter module so it's possible that a combination of the patches posted here and a look at how it's been accomplished in core for D7 could net a better patch for D6. Realistically I can't spend much time on this myself given my day job demands but if you want to take it and run with it then please do so and post patches here.

Great, thanks, we'll take a look and see if there's a good alternative.

-Daniel

Work on this for 7 is happening in #1073026: Implement CTools exportables and export UI

Looks like this can be revisited in D7.