i18n: plus D6 Compatability

I have began to look at it. Is anyone else working on this?

I got an email from someone interested in working on it, but have not heard from that person recently. I had thought that it might be a good idea to try to move towards using CCK, as people seem to want the ability to turn yield off, or don't want the ingredients organised that way etc. It might be worth seeing if there's a way to add recipe's extra functionality (yield, recipeML) on top of a node type installer to reduce the amount of recipe specific code. I don't know when I'll get a chance to progress this idea further, and a straight port to D6 might be quicker/easier and also of interest.

Oh, also, just got this comment on my own website:
http://www.pebble.org.uk/node/20#comment-1
(I've grabbed the code and will put it on pebble.org.uk for download, haven't had a chance to look at it yet.)

Seems to work fine...

And I make a quick and dirty translation to spanish...

Try adding:

if (empty($node_link)) { $node_link=0; }

on line 559 there. Does that help?

I have created a CCK field module for ingredients. I will post when a couple more "features" of the recipe.module are implemented. (Specifically: autocomplete ingredient names and fraction/decimal handling for quantity.)

I guess the open question is whether a CCK implementation of the recipe.module is the way we move forward or if I should create a drupal project for ingredient.module for this development?
-or-
Is there a need to continue development on the non-CCK version of the recipe.module?

I'm having a small issue, nothing critical here.
Using Drupal 6.2, everything is fine with the solution from the recipe's module website. (you should consider puting the code on the 6.X modules pages).

But, I created a recipe for 2 yields, all good, but on the Summary table/box, the Yield field is empty, there's nothing in it. But it's there on the RecipeML and on the Print Version.

I don't know what's the problem:
$form['custom_yield_container']['custom_yield'] = array(
'#type' => 'textfield',
'#default_value' => $node->yield,
'#size' => 2,
'#maxlength' => 4
);
looks fine to me, but $node->yield doesn't show anything. If I put anything else, it's printed there. $node->yield doesn't seem to have any value in that function.

Here's an example:
http://www.froggystyle.ca/?q=node/3

Thanks!

I think ultimately moving to CCK fields is the way forward, but we shouldn't lose functionality in doing so, and we need an upgrade path for existing users. Does anyone know if drupal's CVS policy allows for creating an extra branch for the CCK work? I think until it's ready we should put the 6.x straight port into CVS. (Come to think of it, we should also do a 5.x release.)

brdwor, what would be your preference?

I put the 6.x code into CVS. I created a 5.x-1.0 release and a 6.x-0.1 release. I also created a branch for 6.x.

We can then use HEAD for cck development, initially compatible with 6.x but, we can have an inital goal to implement as feature complete with CCK for 7.x (expecially if cck makes core). In the event that it is not feature complete by 7.x, we can then choose to create a 7.x branch from the 6.x branch and continue working in HEAD on the cck version. Does this seem okay?

I didn't commit any cck related files yet. Let's open another issue tracker for that. Reopen this issue if there are any problems with this plan.

Spanish translation committed also. Thanks, tatxe.

Awesome! Thanks, brdwor!

Found another Spanish translation here. I don't see it in CVS (and there's another es patch pending in a different issue).
Just updating the subject primarily so I can find this translation and use it, if the other one proves incomplete.