I was wondering if making i18n compatible with the PHPtheme engine is practical? My major concern is the fact that with the standard Drupal theme engine, primary links, such as home, about, etc... are covered by translations, but the way PHPtheme engine inserts these links in externally is not. I think the PHPtheme engine is superior for creating themes and is probably getting more and more popular, so this feature for i18n would eventually be more of a priority.

Just a suggestion,

Comments

steffen’s picture

Are you saying that i18n is not compatible with PHPTemplate?

That might explain why I'm having a bit of trouble with it. I couldn't get it to work at all with the 4.5.2 releases, but when pulling the CVS version of both, it works with my PHPTemplate - to some extent.

Right now I'm having trouble with the Events module. Everything is translated, except for the posts... If someone else is having a similar problem, please post in the i18n forum, or the events forum - so I know it's not only me.

jmlane’s picture

No, i18n is compatible with PHPTemplate. I'm successfully running both release version 4.5.2 of Drupal and release 4.5.0 of PHPTemplate, along with release version 4.5.0 of the i18n module. No CVS version or hacks required, I just followed the instructions. :) (Note, you may find some useful patches in the CVS though! I did for i18n.)

I think the issue I'm addressing would be more of an issue with PHPTemplate, how it doesn't handle primary links in the same manner as the standard Drupal theme engine (xtemplate?) does. I'm pretty sure that's the case, however if anyone would know a way that I could hack either PHPtemplate or i18n to display the node title dynamically, instead of the static name used now, in primary and secondary links?

Need clarification? Just ask.

Thanks,

Jonathan

jmlane’s picture

Component: Miscellaneous » User interface

I found this resolved issue, http://drupal.org/node/15267. The use of i18n variables for theme settings doesn't seem to work with the PHPtemplate engine, because it handles the creation of primary and secondary links in a different manner then xtemplate. I'm looking for similar results, but I don't know what would be the easiest way to accomplish this with PHPtemplate.

gjost suggested this method, when using PHPtemplate, but this bypasses the theme settings completely, defeating the purpose of having a theme configuration option for links.

Thanks,

Jonathan

jose reyero’s picture

I'm not using xtemplate but I guess the whole problem is that xtemplate stores that values in variables with different names.

If someone using it could let as know which variable names xtemplate uses....

jmlane’s picture

Okay, I managed to figure out how to do it. I don't know if this is the most efficient way to do it, but it works much better then the proposed solutions above.

PHPtemplate stores links in the 'phptemplate_primary_links', 'phptemplate_primary_links_more', 'phptemplate_secondary_links' and 'phptemplate_secondary_links_more' variables. An easy way to maintain the use of the theme settings interface while having a different set of links for your different languages is to use the i18n variables array in your conf.php file, which makes i18n create a set of those variables for each language.

Incase anyone reading is not familiar with the variable array, simply add something similar to your conf.php file, in the includes/ directory:

$i18n_variables = array(
	// Previous variables you set for i18n would go here...
	...
	// PHPtemplate links array
	'phptemplate_primary_links',
	'phptemplate_primary_links_more',
	'phptemplate_secondary_links',
	'phptemplate_secondary_links_more',
);

I hope someone finds this helpful.

Enjoy,

Jonathan

jmlane’s picture

Title: Intergration with PHPtheme engine » Intergration with PHPtemplate engine
Priority: Normal » Minor

Fixed title for accurate search results and change status to 'by design', incase anyone looking through the feature requests wants to do something similar.

Jonathan

jose reyero’s picture

Thanks, Jonathan

I will add this variable list to the module's documentation, INSTALL.txt, will be in next commit.

I think the right status for this issue is 'closed' now