Preparing for 5.0 string freeze
I know it has not traditionally been something we've done, but I'd really like to do a string freeze @ RC1 if we can possibly help it. For those who don't know the term, a "string freeze" means "everything that's in a t() can't be changed from this point out" unless it's to fix a 'critical' bug; for example, instructions that tell you to click something that isn't actually there. This makes it possible for translators to start kicking into high gear and translating Drupal 5 at the RC phase, so by the time 5.0 is released we have a plethora of options to choose from. So in preparation of this, we need to do the following: a) A large patch, or series of patches, which "clean up" translated strings; stuff like getting rid of \' and change t('<p>blah...') to '<p>'. t('blah...') and such. Which would be best? One patch per file, or a large one that just makes these minor changes everywhere? b) Reading of error messages, help text, field descriptions, etc. for clarity. If something's not clear, we need patches submitted to make it more clear. c) An answer to question posted @ http://drupal.org/node/92992: Should we remove the "You can" links from module help? And if the answer's "yes", then patches to make that happen. (my personal vote is for "yes" since those bloody links were the bane of my existence when I was writing those help handbook2helptext scripts back in the day). Also, anyone have a sense whether the next release of HEAD that's rolled will be another beta release or whether it will be a release candidate? I'd love to get an approximation of how much time I have to work on these issues (and also if anyone's interested in helping). -Angie
Angela Byron wrote:
a) A large patch, or series of patches, which "clean up" translated strings; stuff like getting rid of \' and change t('<p>blah...') to '<p>'. t('blah...') and such. Which would be best? One patch per file, or a large one that just makes these minor changes everywhere?
If one change is questioned, then the whole patch is held back until resolved. If there was one big patch, then nothing is accomplished. But if there are smaller patches, then the others may continue through. Do whatever works best for the situation.
b) Reading of error messages, help text, field descriptions, etc. for clarity. If something's not clear, we need patches submitted to make it more clear.
Maybe not for this release cycle, but at some point I'd like to see written standards for all of these. An example from elsewhere is "Writing Good Alert Messages" in Apple's Human Interface Guidelines, http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuid....
c) An answer to question posted @ http://drupal.org/node/92992: Should we remove the "You can" links from module help? And if the answer's "yes", then patches to make that happen. (my personal vote is for "yes" since those bloody links were the bane of my existence when I was writing those help handbook2helptext scripts back in the day).
A more important issue is figuring out how to get the 'more help' links back on pages like admin/content/comment. The old linking code depended on paths, which all changed. Has anyone posted a patch for this?
Also, anyone have a sense whether the next release of HEAD that's rolled will be another beta release or whether it will be a release candidate? I'd love to get an approximation of how much time I have to work on these issues (and also if anyone's interested in helping).
I haven't thought much about this. I've been reviewing patches and making graphs instead. -- Neil Drumm http://delocalizedham.com/
Status update on this, and replies to Neil's comments. On 15-Nov-06, at 1:26 PM, Neil Drumm wrote:
Angela Byron wrote:
a) A large patch, or series of patches, which "clean up" translated strings; stuff like getting rid of \' and change t('<p>blah...') to '<p>'. t('blah...') and such. Which would be best? One patch per file, or a large one that just makes these minor changes everywhere?
If one change is questioned, then the whole patch is held back until resolved. If there was one big patch, then nothing is accomplished. But if there are smaller patches, then the others may continue through. Do whatever works best for the situation.
Since these were all very minor changes, Gurpartrap completely went to town and rolled one for all of core. You can find it here: http:// drupal.org/node/97824 I've reviewed it twice now, and think it's ready to go, but another few pairs of eyes on this definitely couldn't hurt.
b) Reading of error messages, help text, field descriptions, etc. for clarity. If something's not clear, we need patches submitted to make it more clear.
Maybe not for this release cycle, but at some point I'd like to see written standards for all of these. An example from elsewhere is "Writing Good Alert Messages" in Apple's Human Interface Guidelines, http://developer.apple.com/documentation/UserExperience/Conceptual/ OSXHIGuidelines/XHIGWindows/chapter_17_section_6.html#//apple_ref/ doc/uid/20000961-TPXREF23.
I am 100% behind that idea, and will commit to getting that done during the next release cycle, but if Dries wants to roll an RC early next week, we simply won't have the time for 5.x. :( In the meantime, just a basic "sanity check" will do, I think.
c) An answer to question posted @ http://drupal.org/node/92992: Should we remove the "You can" links from module help? And if the answer's "yes", then patches to make that happen. (my personal vote is for "yes" since those bloody links were the bane of my existence when I was writing those help handbook2helptext scripts back in the day).
A more important issue is figuring out how to get the 'more help' links back on pages like admin/content/comment. The old linking code depended on paths, which all changed. Has anyone posted a patch for this?
There is now! :D http://drupal.org/node/97907 And there is also a patch for removing the "You can" links: http:// drupal.org/node/92992. Additionally, here are some other "stringy" issues: - Improve book.module help text - http://drupal.org/node/97889 (all modules could probably use a once-over like this, actually) - Fix one word links on admin by modules page: http://drupal.org/node/ 97823 - Add "Create X" links to admin by modules page: http://drupal.org/ node/97812 If folks interested in seeing this happen could a) review the patches mentioned in this mail and b) post if there are others that need addressing, that would be great. -Angie
Hi, I'd also like to see http://drupal.org/node/89200 (Remove information about moderation from help page) reviewed. Konstantin Käfer – http://kkaefer.com/
On 11/15/06, Angela Byron <drupal-devel@webchick.net> wrote:
Since these were all very minor changes, Gurpartrap completely went to town and rolled one for all of core. You can find it here: http:// drupal.org/node/97824
I've reviewed it twice now, and think it's ready to go, but another few pairs of eyes on this definitely couldn't hurt.
Well, that patch has now been split apart since it was somewhat mixed between different tasks. For anyone who wants to help or provide reviews, take a look at the Critical Tasks whose titles begin with "String Freeze" http://drupal.org/project/issues?projects=3060&text=Freeze&categories=task&p... There's a whole lot of "(RTBC)" and "(CNR)" - we're getting close. Regards, Greg
Hi, had 5.0 been frozen already? I would like to start making official czech translation and we don't have much time before christmas :-) Thanks, Jakub http://www.drupal.cz
On 12/12/06, Jakub Suchy <jakub@rtfm.cz> wrote:
Hi, had 5.0 been frozen already? I would like to start making official czech translation and we don't have much time before christmas :-)
Thanks, Jakub
Hi all, Dont forgot to look out this issue http://drupal.org/node/10268 before string freeze. Thanks. -- Pushparajan V http://www.vprajan.org - - - - - - - - if(others(love)>=life) { noends=true; lifetime=others(love).length(); } - - - - - - - -
On 12/12/06, Pushparajan V <vprajan@gmail.com> wrote:
On 12/12/06, Jakub Suchy <jakub@rtfm.cz> wrote:
Hi, had 5.0 been frozen already? I would like to start making official czech translation and we don't have much time before christmas :-)
Thanks, Jakub
Hi all,
Dont forgot to look out this issue
oops, sorry.. missed out 9 :) correct link: http://drupal.org/node/102689 before string freeze.
Thanks.
-- Pushparajan V http://www.vprajan.org - - - - - - - - if(others(love)>=life) { noends=true; lifetime=others(love).length(); } - - - - - - - -
-- Pushparajan V http://www.vprajan.org - - - - - - - - if(others(love)>=life) { noends=true; lifetime=others(love).length(); } - - - - - - - -
I don't know the official policy but string changes are still being made to CVS. The "String Freeze" queue has 8 currently active issues: http://drupal.org/project/issues?projects=3060&text=Freeze&versions=96923,10... The RTBC queue (down to 6 issues!) doesn't currently seem to have anything that would affect a string freeze: http://drupal.org/project/issues?projects=3060&versions=96923,100201,94737&s... There has been a lot of progress made with string fixes recently, but we don't appear to be "frozen" yet. My hunch is that we're getting pretty cold though. -Chris Jakub Suchy wrote:
Hi, had 5.0 been frozen already? I would like to start making official czech translation and we don't have much time before christmas :-)
Thanks, Jakub
On 11 Dec 2006, at 22:01, Jakub Suchy wrote:
had 5.0 been frozen already? I would like to start making official czech translation and we don't have much time before christmas :-)
String are not 100% frozen yet, but will be when the first release candidate (RC) is made available. Once the RC is out, we'll try not to break strings unless we really have to. A first RC should be available real soon. (RS) RC RS, -- Dries Buytaert :: http://www.buytaert.net/
On Wed, 15 Nov 2006, Angela Byron wrote:
b) Reading of error messages, help text, field descriptions, etc. for clarity. If something's not clear, we need patches submitted to make it more clear.
The 4.7 release have seen help text edited and refined as handbook pages. Was this only an initial energizing method, or does this method failed? Now it does not seam that the 5.0 help texts will get generated from handbook pages as it seems. My pet issue is that no contrib module should be mentioned in help texts (I will submit an issue later if noone does before me, I am just in a hurry, and unable to submit now). Location module is mentioned at some point in Drupal core. Since it is a contrib module to be installed, I don't think it is OK to mention it at all. Gabor
Gabor Hojtsy wrote:
On Wed, 15 Nov 2006, Angela Byron wrote:
b) Reading of error messages, help text, field descriptions, etc. for clarity. If something's not clear, we need patches submitted to make it more clear.
The 4.7 release have seen help text edited and refined as handbook pages. Was this only an initial energizing method, or does this method failed? Now it does not seam that the 5.0 help texts will get generated from handbook pages as it seems.
The root problem is that help texts are in PHP code. The sets of people who can edit PHP code and write good help text have a relatively small intersection. And the workflow is shorter; edit a page happens much quicker than patch, edit, diff. Help texts as nodes on Drupal.org seems like a fine idea until you have to get them back into Drupal. I hear that part is annoying. It was painful to watch Kieran try and make it work when I was his coworker at CivicSpace. Long term, some sort of magic help system with easy editing fixes this. For now, use the best text storage method for collaborators who are working on a specific text and put up a patch when done. -- Neil Drumm http://delocalizedham.com/
On 16-Nov-06, at 4:28 AM, Gabor Hojtsy wrote:
On Wed, 15 Nov 2006, Angela Byron wrote:
b) Reading of error messages, help text, field descriptions, etc. for clarity. If something's not clear, we need patches submitted to make it more clear.
The 4.7 release have seen help text edited and refined as handbook pages. Was this only an initial energizing method, or does this method failed? Now it does not seam that the 5.0 help texts will get generated from handbook pages as it seems.
The old method did work, but relied on two things: a) Drupal.org offering a book "export" feature, which was since removed from core book module during the 4.7 release cycle. b) Drupal.org exporting books in Docbook format, which was also since removed form the export scripts, in favour of "DXML" (Drupal XML) which provides better context into stuff like "this is a node title" and such (as opposed to merely screen-scraping). So the "docbook2helphook" script I slaved for weeks over last fall has to be completely rewritten now, and I just plain have not had time/energy to do it. It's also problematic because only one version of a given page may live at the handbook/modules/blah URL, and we don't want to scrap 4.7 docs in favour of 5.0 ones until 5.0 is stable. Chicken and egg. For Drupal 6.x, "module.help" files are probably the way to go, and leave hook_help to just little supplemental information about certain pages. Then editing the documentation is just a matter of editing a text file, same as INSTALL.txt. But let's open another thread to talk about future plans. ;)
My pet issue is that no contrib module should be mentioned in help texts (I will submit an issue later if noone does before me, I am just in a hurry, and unable to submit now). Location module is mentioned at some point in Drupal core. Since it is a contrib module to be installed, I don't think it is OK to mention it at all.
Agreed there. I did a quick grep and couldn't find reference to Location module, but if you find it please submit a patch to remove it. -Angie
On Thu, 16 Nov 2006, Angela Byron wrote:
For Drupal 6.x, "module.help" files are probably the way to go, and leave hook_help to just little supplemental information about certain pages. Then editing the documentation is just a matter of editing a text file, same as INSTALL.txt. But let's open another thread to talk about future plans. ;)
OK, so go with patches for now, and we will see how we can improve the situation for 6.0.
My pet issue is that no contrib module should be mentioned in help texts (I will submit an issue later if noone does before me, I am just in a hurry, and unable to submit now). Location module is mentioned at some point in Drupal core. Since it is a contrib module to be installed, I don't think it is OK to mention it at all.
Agreed there. I did a quick grep and couldn't find reference to Location module, but if you find it please submit a patch to remove it.
Looked up my PO files. This was the offending piece, and our corresponding Hungarian translation :) Obviously there is no page.module anymore, so this problem is solved. The conclusion of this is that there should not be a mention of contrib modules like this because users obviously think that there should be a location and/or trackback module to be enabled, but it is nowhere to be found in Drupal core. This was also quite misleading because this remark could have been true for any node type for that matter, not only pages. #: modules/page.module:18 msgid "" "If the location module is enabled, then location specific " "information can be added. If the trackback module is " "enabled trackbacks can be configured." msgstr "<!--silly thing-->" Goba
participants (9)
-
Angela Byron -
Chris Kennedy -
Dries Buytaert -
Gabor Hojtsy -
Greg Knaddison - GVS -
Jakub Suchy -
Konstantin Käfer -
Neil Drumm -
Pushparajan V