Multilingual support
Hi. I'm the author of Localizer, a module alternative to Internationalization, that adds multilingual support to Drupal. For whom interested in details of my module here there are some links : Project page : http://drupal.org/project/localizer Project issues : http://drupal.org/project/issues/localizer Manual, written by a friend, Edward : http://drupal.org/node/103419 (and we are working on a multilingual manual too) I have joined months ago the groups to add multilingual support to Drupal core : http://groups.drupal.org/i18n, where I have posted also my ideas and my proposals. I had joined also the mailing list activated by DevelopmentSeed : http://devseeddev.com/pipermail/internationalization_devseeddev.com/ But, unfortunately, it seems to me that there is not much activity on these communications channels. Reading this post http://groups.drupal.org/node/2781 and taking a look at the Subversion repository here : http://svn3.cvsdude.com/devseed/sandbox it seems to me that some crucial decisions about multingual support in Drupal are already taken, or am I wrong ? For example, if I understand correctly, taxonomy translations will be implemented duplicating the trees, variables will be duplicated in their own table adding a language attribute. Well, I would like to know what is, if exists, the list of features that will be implemented in Drupal 6 to achieve multilingual support, and also the technical solutions that could be adopted. For example, if the variables translation mechanism is definitive, we could think to use it soon, without working now on a different solution that could be abandoned in the next months. For taxonomy we could already port the new patches for the translation, and so on. I'm asking this because I would like, if possible, to avoid duplicating work and to be able to prepare a migration path for the users of Localizer when multilingual support will be in the core, probably, in the next release. As you can see in the issue lists of Localizer, we are working hard and there are some good requests by the users. I wonder if something of all this already done work can be used, at least as logic or idea if not as code. Many thanks. Roberto.
For example, if I understand correctly, taxonomy translations will be implemented duplicating the trees, variables will be duplicated in their own table adding a language attribute.
Hi, i don't like the way i18n implements this. As i tried Localizer module recently, this is solved much better, without need to duplicate taxonomies. Jakub
Roberto Gerola wrote:
Reading this post http://groups.drupal.org/node/2781 and taking a look at the Subversion repository here : http://svn3.cvsdude.com/devseed/sandbox it seems to me that some crucial decisions about multingual support in Drupal are already taken, or am I wrong ?
The decisions will be final once code gets added to cvs on drupal.org. :p IIRC Gabor is working on I18N for Drupal as part of his thesis work.
For example, if I understand correctly, taxonomy translations will be implemented duplicating the trees, variables will be duplicated in their own table adding a language attribute.
Well, I would like to know what is, if exists, the list of features that will be implemented in Drupal 6 to achieve multilingual support, and also the technical solutions that could be adopted.
I am not aware of such a list.
For example, if the variables translation mechanism is definitive, we could think to use it soon, without working now on a different solution that could be abandoned in the next months. For taxonomy we could already port the new patches for the translation, and so on.
I'm asking this because I would like, if possible, to avoid duplicating work and to be able to prepare a migration path for the users of Localizer when multilingual support will be in the core, probably, in the next release.
You probably should contact Goba. Cheers, Gerhard
You probably should contact Goba.
Who is busy until Tuesday when he will most probably write a summary of the i18n mini summit which happened in my flat on Thursday and Friday, with Jose, Goba and me discussing and coding some i18n stuff (they did most of the coding, mostly I just provided some insight and space and corrected some pieces). Thanks for developmentseed for getting Jose here.
On Sat, 17 Feb 2007, Roberto Gerola wrote:
I have joined months ago the groups to add multilingual support to Drupal core : http://groups.drupal.org/i18n, where I have posted also my ideas and my proposals.
I had joined also the mailing list activated by DevelopmentSeed : http://devseeddev.com/pipermail/internationalization_devseeddev.com/
But, unfortunately, it seems to me that there is not much activity on these communications channels.
You intended to write that there *used to* be not much activity. To speak about me, I was working on polishing up some of my modules for the 5.0 release, then doing the same with the Hugarian translation, coming up with automatic localization import, creating an install profile out of this, and support the users having problems, fixing bugs. This is also an i18n related feature intended to come to Drupal 6 core, but it was certainly not an i18n focus group task.
Reading this post http://groups.drupal.org/node/2781 and taking a look at the Subversion repository here : http://svn3.cvsdude.com/devseed/sandbox it seems to me that some crucial decisions about multingual support in Drupal are already taken, or am I wrong ?
I can only repeat Gerhard here. Until code gets into Drupal core, there are no final decisions made. And even then you can submit more patches to enhance, fix and otherwise modify the behaviour until code freeze.
For example, if I understand correctly, taxonomy translations will be implemented duplicating the trees, variables will be duplicated in their own table adding a language attribute.
Well, I would like to know what is, if exists, the list of features that will be implemented in Drupal 6 to achieve multilingual support, and also the technical solutions that could be adopted.
Roberto, you were invited, and you gladly come into the devseed supported focus group. We set up the infrastructure, so we can collaborate on core modifications. There is no other way. Handing around patches for whatever state core is in on your development box does not work. Just as we started off the discussions recently, you asked yourself to get removed from the SVN server for unspecified reasons. It would be nice to discuss these issues in the community I think, and this is why we did an open discussion before. I was busy with the above specified stuff, and have not been able to take the helm to strongly lead. Noone else did it either. You asked to get removed and now you think the discussion is made in a closed group.
I'm asking this because I would like, if possible, to avoid duplicating work and to be able to prepare a migration path for the users of Localizer when multilingual support will be in the core, probably, in the next release.
Maybe you should not ask for given decisions, but be part of the discussion, so we can make a better product together after all.
I wonder if something of all this already done work can be used, at least as logic or idea if not as code.
I will write up a detailed document later next week. We did 12-14 hour work days this week all day i18n discussion and coding at chx's flat (ordered lunch, so we don't need to waste time with going out for lunch), so it is probably better to take a small break now, let the ideas sink down and polish. We did go through on the way discussed earlier in the groups.drupal.org posts, so our outcome will not be surprising for those reading the posts there. Ps. thanks to Development Seed to sponsor Jose flying in for the meeting. Gabor
Hi Gabor. First of all, I didn't want to offend anyone and I don't want to begin a flame war. So, my apologies if in some manner I have written something that can have offended you and your work. It wasn't my intention.
Just as we started off the discussions recently, you asked yourself to get removed from the SVN server for unspecified reasons. Yes, of course, because I have received no news and no answers, neither by the mailing list, nor by groups.drupal.org. I understand you are very busy, there is no problem.
It would be nice to discuss these issues in the community I think, and this is why we did an open discussion before. Yes. I agree.
I was busy with the above specified stuff, and have not been able to take the helm to strongly lead. Noone else did it either. I have made my posts, announcements and solution proposals there in the attempt to help the development. More than this is not possible for me.
You asked to get removed and now you think the discussion is made in a closed group. No, I have only said that in the mailing list and on groups.drupal.org I have not received many answers to my posts, so I have preferred to stop all my activities there.
Maybe you should not ask for given decisions, but be part of the discussion, so we can make a better product together after all. Yes. My proposals, my ideas and my work are all public. My work is donated to the community, so if you think that there is something that can be useful for this project, it is there.
I have made this post only for a reason : to know what is the future of multiligual support in Drupal, from a technical point of view. I prefer to not spend time and efforts on solutions for Localizer now that wouldn't permit an easy port to the Drupal core solution in the next months, and that could leave the Localizer users with unusable systems in their hands, or with the need to rebuild their sites from scratch. I think I am responsabile to make everything I can to prepare a migration path for the users that have believed in me and in my work, so that they'll be able to switch easy from Localizer to the definitive solutions that will be adopted in Drupal core. Thank you for your work. Roberto
roberto.gerola@speedtech.it wrote:
I have made this post only for a reason : to know what is the future of multiligual support in Drupal, from a technical point of view. I prefer to not spend time and efforts on solutions for Localizer now that wouldn't permit an easy port to the Drupal core solution in the next months, and that could leave the Localizer users with unusable systems in their hands, or with the need to rebuild their sites from scratch.
Roberto, we are not thinking in contrib modules now. We are thinking in core patches. It was repeatedly pointed out by Dries that i18n should be a core value of Drupal. You probably need to evaluate whether you would like to work on "solutions for Localizer" or solutions for Drupal core, if you don't have the time for both. I did choose the later. What core maintainers will be interested in is the following: - a list of the problems with Drupal if we need to implement i18n features - some proposed solutions for core, and how they interact with future contrib features - easy extension points for contrib authors, so they can easily enable their modules for i18n - benchmarks of the solutions, so it can be shown that we will not slow down Drupal for those, who are not interested in these features So in some sense, these need to be deeply in core, albeit easily usable, so they can be reused, and can have an impact on contrib modules supporting i18n, but then they need to have as small a performance impact if not used as possible. For this to work, we need core level solutions (patches to be clear). We did have a groups.drupal.org group, where higher level discussions were done, and now we have an SVN repository which recently became active, as it was possible to build something with the new menu system and especially the new url()/l() changes, which made the page generation code much simpler and more performant. The changes we made would not be possible with the old menu system and url()/l() simply for performance reasons. We have a mailing list, where any member can comment on patches made, so we can discuss code directly. If you have better ideas for any of the patches we make, you can just hit reply. I have seen you starting two threads, one of which we closed as far as I have seen. The other did have information not new for me, but anyway, I just replied to it. Maybe we can go a bit deeper there and discuss the implementation details now that we have a useable temporary Drupal fork to work with. I have looked at the documentation you pointed to written by your friend Edward, and it seems to be a nice end user guide. What we need for Drupal core is a lower level focus. I did a deep code review of your module a few months ago (as part of writing the i18n report), but given the amazing pace of the work you do, it is not easy to keep up with how and what you change. Your adoption speed to new ideas is very good for the Localizer module, but some developer level documentation (or at least lower level explanations in discussions) would be much more useable in our work.
Thank you for your work.
Thank you for your work! You did bring some new ideas into the equation, so being a fresher mind around Drupal i18n (at least compared to some of us) is a very good news for us. Keep collaborating! Gabor
Gabor Hojtsy wrote: Hi.
Roberto, we are not thinking in contrib modules now. We are thinking in core patches. It was repeatedly pointed out by Dries that i18n should be a core value of Drupal. You probably need to evaluate whether you would like to work on "solutions for Localizer" or solutions for Drupal core, if you don't have the time for both. I did choose the later.
To be honest, I think I know very little about Drupal core and its internals, and I think I couldn't be very productive working on that side. So probably I can give my best contribute on external modules. I have collected in this months many requests by the users, so I think that I could make a list of these features and pass them to you, so we can see together where the changes in the core impact and are necessary.
So in some sense, these need to be deeply in core, albeit easily usable, so they can be reused, and can have an impact on contrib modules supporting i18n, but then they need to have as small a performance impact if not used as possible.
Absolutely.
We have a mailing list, where any member can comment on patches made, so we can discuss code directly. If you have better ideas for any of the patches we make, you can just hit reply. I have seen you starting two threads, one of which we closed as far as I have seen. The other did have information not new for me, but anyway, I just replied to it. Maybe we can go a bit deeper there and discuss the implementation details now that we have a useable temporary Drupal fork to work with. Well, I think this is my last post here. I think it has more sense that the discussion now proceed on that dedicated mailing list, if you agree.
I have looked at the documentation you pointed to written by your friend Edward, and it seems to be a nice end user guide. Yes, Edward has written it from a final user point of view. My first instructions were too technical and weren't of much help for the new users.
What we need for Drupal core is a lower level focus. I did a deep code review of your module a few months ago (as part of writing the i18n report), but given the amazing pace of the work you do, it is not easy to keep up with how and what you change. Yes. I can understand.
Your adoption speed to new ideas is very good for the Localizer module, but some developer level documentation (or at least lower level explanations in discussions) would be much more useable in our work. Well, I'll see what I can do in the next days / weeks. I'll try to prepare some technical notes to explain the solutions adopted. I have no problem to admit that some solutions are very bad and I am trying to improve them in these days.
Thank you for your work! You did bring some new ideas into the equation, so being a fresher mind around Drupal i18n (at least compared to some of us) is a very good news for us. Keep collaborating! I'll do all my best to help.
Roberto
Roberto Gerola wrote:
I have collected in this months many requests by the users, so I think that I could make a list of these features and pass them to you, so we can see together where the changes in the core impact and are necessary.
Great!
Well, I think this is my last post here.
Maybe on this thread or in this topic :) It did sound scary on first read, before reading on :)
I think it has more sense that the discussion now proceed on that dedicated mailing list, if you agree.
Good!
Well, I'll see what I can do in the next days / weeks. I'll try to prepare some technical notes to explain the solutions adopted. I have no problem to admit that some solutions are very bad and I am trying to improve them in these days.
I'll do all my best to help.
Amazing! :) Keep rocking on! Gabor
participants (6)
-
Gabor Hojtsy -
Gerhard Killesreiter -
Jakub Suchy -
Karoly Negyesi -
Roberto Gerola -
roberto.gerolaï¼ speedtech.it