- Development - lists.drupal.org

updating translations: how valuable is user data after all?
by Gabor Hojtsy 23 May '07

23 May '07

Hi guys, Now Drupal 6.x-dev includes cool features to import PO files automatically at every logical step: - you can install Drupal in your foreign language, and have PO files for all enabled modules imported along automatically - when you add a new language, all translation files for enabled modules get imported automatically for that language - when you install new modules or enable themes, the translation files for these components get imported for all enabled languages This is all great and automated, contrib modules already have their PO files at the right place, and we will update the packaging scripts for Drupal 6 to package core translations properly. You might notice a pattern in the above features though: they IMPORT stuff into the database. Unfortunately we have no way in Drupal 6 to remove translations when you disable a theme or uninstall a module. We don't know what strings appeared in *only* that component, and not elsewhere in Drupal, so we can remove them without problems. For that, we would need the extractor script built into Drupal core to look through all source files of enabled components and identify the unused strings in the database. Fortunately this is doable in contrib, now that extractor has it's own Drupal module. (Of course it is doable in Drupal core my deleting all strings from the database and reimporting files for only the enabled components, but read on about the value of user data). BTW Drupal 6 core still need upgrade support for translations. So when you update a module or Drupal itself, new and corrected translations get into your database. New translations are easy again, they are just importing new stuff, which we are very good at :) Updating translations already in the DB threatens user data though. In Drupal 5 and before, we have no information about what translations a user modified on the web interface, so we don't know what was imported from available PO files and what was user defined. We can reimport stuff from the files, but can easily loose/overwrite user defined/updated strings. What can we do about not to loose user defined strings? We can easily introduce a 'modified' bit into the locale translations (target) table, just as it was in menu module in Drupal 5. That would help us from Drupal 6 onward, but it does not help us loosing user defined strings when a Drupal 5 to Drupal 6 upgrade happens. So how cautious should we be there? 1. Do not overwrite any existing translation, risking that we leave incorrect and fixed translations in the database. 2. Do overwrite existing translations on an update, risking that we overwrite user modified translations. Note that an update will not *remove* anything from the DB because we don't know what we can remove as explained above. It can *overwrite* stuff though, and problems are around these overwrites. So how should the update paths work for Drupal and for modules/themes? Gabor

4 11

drupal.org downtime tomorrow
by Gerhard Killesreiter 23 May '07

23 May '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 see http://drupal.org/node/145947 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGUzsQfg6TFvELooQRAg77AKCrKdoiVqkRphbsvspgbs0stcA6HACgsWUe vdoGZXmbjNuCbpAlN6uzXcM= =tfXZ -----END PGP SIGNATURE-----

5 6

Re: [development] drupal.org downtime tomorrow
by Matt Farina 23 May '07

23 May '07

2 1

Patches - code freeze
by Dries Buytaert 23 May '07

23 May '07

*** Larry wrote in another thread: > In addition to claiming modules to work on, if there are any > pending patches that make substantial changes to a core module that > need to go in before code freeze let us know about those, too, so > we can not touch that module yet. This performance refactoring can > stretch post-1 June I believe since there's no API changes (Dries, > correct me if that's an incorrect statement), and I'd rather not > block someone else's patch that's almost-there. :-) There are a lot of patches really, and we could use a hand reviewing those. And when I say "reviewing", I mean "studying the code and thinking it through" rather than just showing your support to the author of the patch. We could use more "in-depth reviews" to help some of the bigger patches move forward. I'm currently on the train so I can't check the issue queue, but at the top of my head (and afraid to miss out on some other important patches), here is my top-6 things I'd like to see us focus on. In order of priority: 1. Getting the pending i18n patches into Drupal core -- I'd rather not ship with a half solution. 2. Getting OpenID into Drupal core. 3. Getting actions into Drupal core. 4. Getting schema API into Drupal core. 5. Paving the path for webservices: data API, being more XML/REST/ JSON friendly, etc. 6. Getting more of CCK into Drupal core. Most of these patches are important for Drupal's future. If we can't get them in by the code freeze, this means that these features might have to wait another year (!) to get into Drupal 7. Having to miss out on these for one year, might be a really long time ... for various reasons, I'd rather not see that happen. At the same time, I'm still looking for patches that help improve the user experience or that help improve performance. Most users don't really care about the architectural changes that happen under the hood; they care about bling and ease-of-use. So things like forum module improvements, more accessible terminology, tracker improvements, easier access control, upload/file handling improvements, search module improvements, are no-brainers that tend to jump to the top of my TODO/review-list. But when these don't make it into Drupal 6, they'll be able to live in contrib for a while and most of the time, that's perfectly fine. An exception is the update_status.module that Earl and Derek are working on -- we definitely want that in core even though it is not an architectural change. It's not always black and white, but in general, the patches that I care most about at this point in the release cycle -- and which I encourage *you* to care most about as well -- are architectural changes that impact the future of Drupal. Of course, these are more difficult to grok and review, but when you do, you'll have a bigger impact on our future. :-) -- Dries Buytaert :: http://www.buytaert.net/

2 2

Drupal's CVS policies... including 'foriegn' code in TinyMCE module?
by Kevin Reynen 23 May '07

23 May '07

I've been working the TinyMCE issue queue for a few months now. IMHO, a large number of the issues users have would be eliminated by including Moxiecode's TinyMCE code in the module with a default configuration that allows all valid HTML... eliminating both the two step install issues as well as the double filter issue. This would both make users happier and free up more of my time. Originally, I was concerned about GPL vs. LGPL. When I asked for advice about that, JohnAlbin advised me that I could distribute LGPL code with a GPL project. I'm not GPL expert so I asked Moxiecode how they interpreted the licensing and they don't have an issue with including their code with the TinyMCE module (http://tinymce.moxiecode.com/punbb/viewtopic.php?pid=21769#p21769) Now Borris is saying the issue isn't GPL vs. LGPL, but policies specific to Drupal's CVS and because some of the key Drupal maintainers are "WYSIWYG haters", I'm not going to get any support I'd need for waving the "no foreign code in CVS" policy. I understand why many developers don't like WYSIWYG toolbars on principle, but a solid WYSIWYG is often key to making Drupal installs user friendly enough for the non-developers/SMEs who are (hopefully) doing the majority of the content work. If it wasn't for WYSIWYG, I'd be deploying something other than Drupal that has a solid WYSIWYG option. There are many legitimate reasons not to support this request, but please don't make it more difficult to distribute a better WYSIWYG editor because in your ideal world everyone knows HTML and there is no need for WYSIWYG. How many people learned to write postscript because a sysadmin didn't install print drivers? Another potential solution we've discussed is pointing users to a TinyMCE download outside of Drupal.org's CVS that includes the Moxiecode code. This is easy enough to do, but would result in TinyMCE dropping off of any top download lists. IMHO, lists like Greggle's Download Statistics for April are really important to help new users determine which contrib modules are stable and supported. Nothing draws a crowd like a crowd. If webchick's IA redesign (http://groups.drupal.org/node/3769) is any indication, it seems the trend is to do more with these stats in the future. I'd hate to choose between forcing new users to rely on "word of mouth" to find TinyMCE and making it a better, more user friendly module. I'm hoping I've made the case for why I want to include the TinyMCE code in the module as well as why I'd like to see that code continue to be distributed through the Drupal CVS instead of taking it offsite. Anyone have an option we haven't thought of? - Kevin Reynen

18 38

Re: [development] Conditionally include include files
by Ken Rickard 23 May '07

23 May '07

Larry said: >I've assigned myself aggregator to start since I don't think anything >particularly interesting is happening with it, so it's reasonably >collision-safe. Well, Aron Novak is doing Summer of Code on it, but his work won't hit D6. But there is lots of interesting work being planned for Aggregator and its legion of contrib spawn. See http://groups.drupal.org/rss-aggregation. Aggregator is also quite self-contained, so it shouldn't pose any difficulty to chop up. - Ken Rickard agentrickard

1 0

Re: [development] Patches - code freeze
by Peter Wolanin 23 May '07

23 May '07

I would still very much like to get some sort of book module overhall done, but it really can't start until this patch is in: http://drupal.org/node/145058 The minimal idea would be to use the menu code to make the book menu block, which should (I hope) be much faster than how book module does it now. Also, I feel like it's a high priority to provide additional help to Karoly to get menu module to work (at all). For the code freeze, is it better to try to get new functionality in, rather than actually doing the work of writing update functions? Is it better to leave one core module (menu) broken on the assumption that later patches will have to go in so that we can refactor book module? I feel like I'm in a lose-lose situation. -Peter > ---------- Forwarded message ---------- > From: Dries Buytaert <dries.buytaert(a)gmail.com> > To: development(a)drupal.org > Date: Wed, 23 May 2007 09:24:19 +0200 > Subject: [development] Patches - code freeze > > There are a lot of patches really, and we could use a hand reviewing > those. And when I say "reviewing", I mean "studying the code and > thinking it through" rather than just showing your support to the > author of the patch. We could use more "in-depth reviews" to help > some of the bigger patches move forward. > > I'm currently on the train so I can't check the issue queue, but at > the top of my head (and afraid to miss out on some other important > patches), here is my top-6 things I'd like to see us focus on. In > order of priority: > > 1. Getting the pending i18n patches into Drupal core -- I'd rather > not ship with a half solution. > 2. Getting OpenID into Drupal core. > 3. Getting actions into Drupal core. > 4. Getting schema API into Drupal core. > 5. Paving the path for webservices: data API, being more XML/REST/ > JSON friendly, etc. > 6. Getting more of CCK into Drupal core. > > Most of these patches are important for Drupal's future. If we can't > get them in by the code freeze, this means that these features might > have to wait another year (!) to get into Drupal 7. Having to miss > out on these for one year, might be a really long time ... for > various reasons, I'd rather not see that happen. > > At the same time, I'm still looking for patches that help improve the > user experience or that help improve performance. Most users don't > really care about the architectural changes that happen under the > hood; they care about bling and ease-of-use. So things like forum > module improvements, more accessible terminology, tracker > improvements, easier access control, upload/file handling > improvements, search module improvements, are no-brainers that tend > to jump to the top of my TODO/review-list. But when these don't make > it into Drupal 6, they'll be able to live in contrib for a while and > most of the time, that's perfectly fine. > > An exception is the update_status.module that Earl and Derek are > working on -- we definitely want that in core even though it is not > an architectural change. > > It's not always black and white, but in general, the patches that I > care most about at this point in the release cycle -- and which I > encourage *you* to care most about as well -- are architectural > changes that impact the future of Drupal. Of course, these are more > difficult to grok and review, but when you do, you'll have a bigger > impact on our future. :-) > > -- > Dries Buytaert :: http://www.buytaert.net/ > > > > -- > [ Drupal development list | http://lists.drupal.org/ ] >

1 0

Re: [development] PHP5 going forward
by Michelle Cox 23 May '07

23 May '07

On 5/22/2007 9:49:54 PM, Larry Garfield (larry(a)garfieldtech.com) wrote: > For the date itself, it couldn't be before 2008 sometime. I'm thinking 1 > > January or 1 April, but that depends on the other projects involved and > how > long it takes to agree on a date/version. TBD. Not sure April 1st is the best idea for a date... ;) Michelle

4 3

Conditionally include include files
by Dries Buytaert 23 May '07

23 May '07

Hello world, I just committed patch http://drupal.org/node/140218, which enables us to split module files into multiple (include) files. With this patch, it is the router's (menu system) responsibility to load the correct include file -- i.e. the include file that has the active callback's code. In other words, depending on the active callback, Drupal can conditionally load include files rather than having to load the entire world. This is an important patch as it enables us to load less code -- hence, it can offer an important performance boost. Kudos to all the people who helped make this possible. :-) The patch that has been committed implements the system to accomplish that, but doesn't actually split modules. There is only one new .inc file that has been committed with this patch that acts as an example. Now this patch landed, the natural next step would be to fire up your profilers, and to split a couple more big modules in Drupal core -- and to report back the performance improvements that you observe with that. -- Dries Buytaert :: http://www.buytaert.net/

4 4

Per content type comment moderation settings
by Boris Mann 23 May '07

23 May '07

The subject says it all....this seems like it would be a simple module, to set per content type moderation settings. For instance, allow forum comments to be published immediately, but blog comments to be pre-moderated. Anyone know of something that can do this? If not, anyone have time to write a quick module to accomplish this? -- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com

2 1