Hello,
I am a writer with years of professional experience and a passion for web usability. I'd like to copy edit the Drupal core ui text.
Simple copy editing can dramatically improve usability and user-friendliness. Drupal would be easier to learn and use by, for example, eliminating repetition and unnecessary words.
To give you an idea of what I have in mind, let's take a look at this dreadful ui language from Drupal 6's admin/build/block page:
This page provides a drag-and-drop interface for assigning a block to a region, and for controlling the order of blocks within regions. To change the region or order of a block, grab a drag-and-drop handle under the Block column and drag the block to a new location in the list. (Grab a handle by clicking and holding the mouse while hovering over a handle icon.) Since not all themes implement the same regions, or display regions in the same way, blocks are positioned on a per-theme basis. Remember that your changes will not be saved until you click the Save blocks button at the bottom of the page.
Click the configure link next to each block to configure its specific title and visibility settings. Use the add block page to create a custom block.
Now consider my copyedited version:
On this page you can set a block's title and visibility with the 'configure' link; assign a block to a region through the drop down menu; and assign a block to a region or arrange block order within regions by dragging the target icon. (Blocks are positioned relative to the current theme; themes often implement regions in different ways.) The 'add block' tab creates a custom block.
Click the 'Save blocks' button below to save your changes.
I'm ready to go through the ui text: I think it will greatly improve Drupal. Let me know how to get started.
-- Will Hall
Comments
Drupal 6 String frozen
Hey Will
Glad to see concrete suggestions of usability improvements for Drupal.
If you want to change things like that you need to focus on D7. Drupal 6 is string frozen which means the core team won't accept any changes to (ui) strings.
For D7, simply suggest replacements as patches and post them as issues..
http://drupal.org/project/drupal
I'd simply start submitting one or two sample replacements and wait for D7 maintainers to confirm you to continue this way.
Yes, Drupal 7
Miro's right - to give translators time to translate the interface before release, and to avoid them having to re-translate the same version many times, major versions of Drupal get string frozen a few weeks before release - some time between beta and release candidate I think. The good news is there's still plenty of time to changes strings in Drupal 7.
The only way stuff gets changed is if people supply patches - if you're comfortable creating a patch yourself, that's great. If not - there's resources at http://drupal.org/patch/create or people in the #drupal irc channel would be happy to walk you through it. Otherwise you can open tasks/bugs with the associated replacement and try to get someone to roll the patches for you - but it'll be quicker and easier to learn how to do it yourself IMO.
thanks catch -- i posted an
thanks catch -- i posted an Issue - so that's going to be slower? I don't really understand the process?
It sounds like there are several stages -- one is doing the copyediting. the next is actually inserting the revised ui text into the actual drupal files. The patch is really about the latter right?
Yup, everything you want
Yup, everything you want changed in Core has to go trough an issue. It will always take a while as people look over it, write code and then iterate on that code until it's good - then someone who can submit code to the core, will submit it.
Ah ok, that makes sense, and
Ah ok, that makes sense, and I just submitted this as an Issue. So now a maintainer will mentor my issue? I guess I'll find out! Thanks - Will
Can you help me with
Can you help me with something else? How do I email directly the users of this forum? I don't see a PM or Send Email link by their profiles.
Part of what inspires me to do this is a simple workflow of finding ui text that is rough, analyzing the page it is on (the block ui text didn't reflect the block page's functionality), then rewriting and submitting. I'm afraid that if I have to get into the back end of Drupal development dialogues, hang out on irc and such, my inspiration is lost.
I can't imagine how complicated a collaborative open source development project is! A lot of work. Perhaps ui text is controversial for some reason or very difficult to get consensus on changing. So I understand if my workflow vision is unrealistic, but is there some way for me to participate?
Advice appreciated
No direct email
As this is an website out in the open, people don't give their email adress in plain text.
If people have accepted that you can contact them, you go to their profile and send a message from the "Contact" Tab.
If you really want to do core work, you will have to armour yourself with patience. This won't be quick, not at all. Drupal is a giantesque project, and things need iterations to become reality.
Hanging out in irc is a real fun side of it all. Meet people directly, find out what they think. Many an idea you (or me) think is brilliant can be put to rest very quickly.
What you can try to do is to find a "mentor" who is interested in what you do and can help you into the Drupal way of doing things. Or team up with someone, which I personally believe is the most motivating way of getting ahead. I also believe there was a guy wanting to do something very similar as you: cleaning up all the (admittedly often horrible and far to long) descriptive texts. I don't find the issue anymore, maybe someone else can help with this.
Life is a process
Life is a journey, not a destination
thanks for reply. i
Thanks for reply. I understand about the email plain text -- I wasn't seeing a 'contact' button or tab for the person I was thinking of, I guess they haven't activated it.
I'm with you that life is a process, but I have often seen in reviews of Drupal that the ui and end user experience are considered among the weakest parts of the platform. Ui text is centrally important to a software's success: good grammar defines successful technology, business, and organizations. Check the top businesses: the copy editing is impeccable.
How do I locate a mentor? I mean, that block text is really pretty bad.
-- Will
What we've all forgot to
What we've all forgot to mention so far is that we're really happy you are offering your help on improving this part of Drupal! :-)
AFAIK, practically, we'll need to supply separate patches per each of the core modules. Which makes it quite 'vertical', whereas of course inconsistentcies are rather 'horizontal' problems across the system. Let's use this thread to further work out a workflow for the part before actually diffing a patch etc.
So, please do tell what you think would be a good workflow for a copy writer.
I've been using the Localization Client module to translate the interface from within Drupal, it works quite nice. I created my own empty "human english" translation and edit stuff down all over the place, on a most-annoying-first basis as I encounter them. It would be great if we could work out a process where we can edit across the whole of Drupal and have some per-module patch writing automagic.
It's quite essential for the Drupal UX to get this off the ground, your timing is excellent and I'm really glad you posted. Contact me anytime, but know that the right people are already responding right here, so let's talk further about:
Word. ;-)
Open Source Culture
Will,
There is no formal mentoring program.
This is open source culture, for better and for worse. It's mostly "for better," in my opinion, but it can take a while to learn, and requires patience at times -- especially regarding changing "core."
You would get a mentor by befriending someone who is experienced in the project, already has credibility and is interested in what you want to do. You can get to know people via IRC, participating in the issue queues, going to a local Drupal meeting if there is one in your area.
And really, it's "learn-by-doing"; the fact that you've created an issue with some alternative text is a great way to learn. Just be warned that people will most likely have feedback for you and settling on a finished replacement text will take time.
Re: Drupal, sometimes I tell clients, "Sometimes you can do incredibly powerful things so easy, and sometimes simple things are really hard to do." I think that applies to the Drupal community development process as well. If you have an itch to scratch that can be solved with a snippet or a module -- you could code it and have other people using and testing it no time (assuming its of some general interest). Very little bureaucracy or anything to stop you. But with changing core, even for string changes, it requires patience and deliberation.
I'm presuming you know that for your own Drupal installations you can use the core "Locale" module to change any strings you want.
Anyway, welcome aboard!
Shai
Content2zero
Shai Gluskin
Content2zero
I also believe there was a
I guess you mean Keith Smith. He will welcome your help.
I'm in too... have exchanged thoughts with webchick previously
The wording in Drupal runs the full gamut: from verbosity to tautology!
I'd love to help shorten it.
For me it starts with the ponderous Admin menu titles themselves:
Content management * Site building * Site configuration * User management * Reports
which I distill to:
Content * Parts * Settings * People * Logs
on my own sites.
Having read the thread to this point, I'm unclear after all that process gubbins on how non-patch-roller types can most easily collaborate -- but let's try!
cheers,
Adrian
Adrian Russell-Falla
412 NE 57th Ave
Portland OR 97213-3716 USA
adrianrf [GTalk/Skype/iChat] * zxadrian [AIM] * 478122434 [ICQ]
cheers,
Adrian
Adrian Russell-Falla
412 NE 57th Ave
Portland OR 97213-3716 USA
+1-503-381-4678 :mobile/Jajah | +1-503-235-9570 :land/Jajah
adrianrf :GTalk/Skype/iChat | zxadrian :AIM | 478122434 :icq
oh hi there, you're in
oh hi there, you're in Oregon too.
Well your example
is a great example of how difficult this can be. You're not just doing copy editing you are doing rewriting. Your own style comes through strongly in the word choices, less enforcement of simple grammatical copy editing principles. There is a gray area between editing and rewriting, so I am thinking it's best to start with ui text that clearly needs copy editing and go from there.
If you did want to work on the Admin menu titles I do think it would be worthwhile, but I think in that case a broader discussion would be in order. I would look at:
How do other software systems use these terms? What will Drupal users be familiar with? How accurately do the titles reflect the content? Is there logical consistency?
For example, I would suggest that "Logs" is not a good word choice because it does not by definition include Status Reports, which is a sub-item. 'Parts' is also too unspecific: all the other items have 'parts.' 'People' does not reflect Drupal's use of 'Users;' and not all People are Users.
To take this further, I would say the Admin menu is not crying out for copy editing like other parts of the ui text. However the main problem with the Admin menu titles is the distinction between 'building' and 'configuration.' Everything has a configuration; and many admin changes are a kind of building. The distinction between the two categories, and what will be found within, is unclear.
To explore this, let's look more closely at what is under Building and Configuration, looking for a logical way to group them. (Complicating this is how different modules admin menus appear depending on what is enabled...)
Site building
Control how your site looks and feels.
Blocks
Macro engine
Menus
Modules
Themes
URL aliases
Views
Site configuration
Adjust basic site configuration options.
Actions
AddThis
Administration theme
Audio import settings
Audio settings
Clean URLs
Comment Subscribe
Date and time
Devel Themer
Devel settings
Error reporting
FCKeditor settings
File system
File uploads
Google Analytics
IMCE
Image toolkit
Input formats
Logging and alerts
Performance
Search settings
Site information
Site maintenance
Taxonomy Browser
getID3()
My first response is that the distinction between Building and Configuration was just a way to break up a lot of similar items into two groups for visual ease. There doesn't seem to be a logical grouping here.
Looking more closely, maybe a case can be made that some of these items are realistically going to be set during theme development; others are going to be used after the theme is developed? Or maybe not. Needs more assessment. But this is very nuanced, so, again, I don't think it is a candidate for easy copy editing.
Maybe I would re-group some of the items as well as renaming the categories:
I would go with something like
Site Design
and
Site Configuration
or maybe
Site Appearance
and
Site Functioning
But again the items under each are very similar, and deciding which items to move and exactly what to rename would be tricky. I don't think that changing to Parts and Settings is going to help overall or is a clear-cut improvement.
Since this is such a central menu and so many eyes have looked at it, the persistence of this problem has some etiology: the original confusing naming probably reflects that the task itself of grouping these items is itself complex. That's moving out of the realm of copy editing into rewriting. Worth doing but a deeper task.
In copy editing it takes a very careful eye to maintain faith to the original meaning and not make stylistic choices where grammar and logic are called for.
-- Will
Re-working the admin
Re-working the admin categories (and their items) is being worked on here: http://drupal.org/node/228236. Not the easiest one to start with but certainly needed.
Thanks for the pointer, Yoroy.
cheers,
Adrian
Adrian Russell-Falla
cheers,
Adrian
Adrian Russell-Falla
412 NE 57th Ave
Portland OR 97213-3716 USA
+1-503-381-4678 :mobile/Jajah | +1-503-235-9570 :land/Jajah
adrianrf :GTalk/Skype/iChat | zxadrian :AIM | 478122434 :icq
Good points, and...
Will, you make some good points. "Reports" vs. "Logs" is fine; "Parts" could perhaps be improved upon; am certainly keen to argue it out. (I come from the advocacy tradition.)
however, your rewriting/copy-editing distinction seems a tad strained.
it confines you to the smallest incremental improvement in usability terms, versus Making Things Optimal.
I do recognize that it's less likely to run into habit-based resistance from "Insiders", but I have no great liking for taking the easy way out anyway.
I'm a twenty-five year veteran of the US and UK software industry, with experience across the board for multi-million horizontal sellers and narrow vertical apps alike: from doing tech support; writing docs; and indeed every part of the marketing process, including copywriting for ads, direct-mail etc.; the whole nine yards through product line management. based on my (often painful) learning to date, I have indeed grown a prejudice: I highly prefer what we might call (if we were greybeard members of L'Acadamie Francaise) 'ces mots brut de l'Anglo-Saxon':
"Configuration" is an utter bastard term: 5 syllables, 13 letters, and highly abstract. it's absolutely not Early Learner English. that means that its penetrative / associative value / emotional connection is nearly nil. it's indefensible!
Drupal's long-standing use of "users" is simply an unchallenged parroting of old-school DP/IT Priesthood pomposity. it's distancing, dismissive, and wrong. let's not forget that Drupal first came from people for whom English was a second language, and who started the project from the academic groves. those beginnings have yielded a wonderful gift, but could never bode well for creating friendly mass-market terms from the get-go.
why would you repeat "Site" redundantly, as in
"Site Design / Site Configuration" or
"Site Appearance" / "Site Functioning"?
I give you the "Harvard MBA 3 reasons":
offers ways to add/subtract entire chunks of functionality, with atomic specificity per domain. you create/turn on/turn off modules, themes, views, blocks, aliases, imagecache presets, etc.
tweaks systemic parameters, i.e. attributes with global scope
I'm sure you're right about the prior logic for breaking a giant list in half, and that the split was likely fairly arbitrary.
however, let's not be deterred by evolutionary ancient history in considering the best path forward -- while at the same time fully respecting the sincerity and value of past work. the key miracle of software is that it is infinitely malleable, and lends itself to whatever degree of transformation will best help it meet the evolving need. Drupal began as a tool for Dutch IT students; their vision and determination has been so successful that the current much wider community clearly has much wider needs and aspirations. I say the founders' investment merits the best possible contributions on the language & messaging front one can muster, not the least change required.
are you in Portland? do you drink beer?
best,
Adrian
Adrian Russell-Falla
503-381-4678 [mob]
LinkedIn: http://www.linkedin.com/in/adrianrf
adrianrf :GTalk/Skype/iChat | zxadrian :AIM | 478122434 :icq
cheers,
Adrian
Adrian Russell-Falla
412 NE 57th Ave
Portland OR 97213-3716 USA
+1-503-381-4678 :mobile/Jajah | +1-503-235-9570 :land/Jajah
adrianrf :GTalk/Skype/iChat | zxadrian :AIM | 478122434 :icq
Hi everyone, thanks for the
Hi everyone, thanks for the insights. Yes I am on board with the values of open source culture, and thanks for reminding me that it may take time and patience to understand how to fit in.
I'm going to email Keith Smith and point him to this thread.
I guess what I want to propose is this: Can I be a volunteer outsourced writing consultant for revising ui text in Drupal? Someone else handles the more challenging vetting negotiations and interaction? That is going to allow me to do the work.
It's sort of like wanting to volunteer for Obama but not wanting to go to any planning meetings. I'm happy to stuff envelopes or make phone calls so to speak. Is that possible?
While I really believe in the open source culture, my inspiration to contribute is very specific here, and hopefully there can be a diversity of engagement and commitment levels, and space for 'outsourced volunteering' like I am proposing.
Patiently,
Will
What I could do, for
OK so I posted here for the blocks page:
http://drupal.org/node/340535#comment-1132774
What I could do, for example, is provide two html pages - one with the existing ui text as it is, and the other with the copy edited ui text I propose. Then they could be put into the patch file. That would be a good workflow for me.
before/after text?
HTML isn't necessary. A copy/paste of the existing text, and a copy/paste of your proposed text next to each other would make it very easy for someone to roll a patch (HTML would make it harder since they'd need to remove markup). Many core interface text changes have been done that way. Like you mentioned, reading patch files isn't always the easiest way to review textual changes - so if you're mocking up in HTML, screenshots can be helpful too (again before/after helps).
As mentioned, another very useful thing is providing feedback on existing issues - a direct link to all specifically user interface text related issues is: http://drupal.org/project/issues?projects=3060&components=user%20interfa... - this is also where you'll find people who are likely to be interested in working on interface text - and checking that queue is a good place to find where issues have already been identified but not solved yet.
OK so I'm still a little
OK so I'm still a little confused on the workflow here. Yes a text file with comparing different texts, original and revised, would be easy for me to do as well. Can you help walk me through what my work flow is? That url is very helpful thanks.
Ok so I am thinking my workflow is this:
Go to the ui issues list and chose a ui text issue
In the comments paste the original and my revised versions.
If there is already a patch submitted, ask the patch author to provide me the text in plain text, so I can work on their revision, not the original unrevised version.
Does this make sense? thanks! - will
Hi Will. I just replied to
Hi Will.
I just replied to your issues in the core queue. We can follow up on those particular strings there.
Again, thanks for hanging in there and working on this. I know it can be frustrating to figure out how the community works. But, we certainly can use the help and I'm glad you're onboard.
Essentially (I guess), there's a couple of ways of doing this.
As other folks in this thread have mentioned, contributing is a very rewarding experience, but it can be sometimes take some time to get your changes implemented. Some tips, in no particular order:
Good luck -- I think you found my contact tab, but please feel free to e-mail me directly and I'll help you as much as possible.
Thanks keith and everyone,
Thanks keith and everyone, this is great. Keith I'll email you directly and get started. - Will
list of terms
I'd like to start on a very basic level:
let's create a list of terms and what they mean, like a drupal glossary or dictionary, such lists are also often called a terminology.
Such a list helps programmers to name / identify items and will help translators to build list with translation of often used terms.
To build such a terminology tools like a concordancer (http://en.wikipedia.org/wiki/Concordancer) can be used.
I'm willing to help, give me a hint how we can start.
In my opinion, it would be great to have correct naming of all items and push these terms into contrib modules.