I want to change the tab's title from "Personal information" to "Personal settings" in all related sections like site/##personal-information and site/##personal-preferences
Any idea where I can set it?
Or is it OK to solve it with Diazo or jQuery?
We did a JS-solution once, when the usecase was for a handful of content-managers who certainly would not disable Javascript.
To be compliant with the Web Content Accessibility Guidelines (WCAG), you want to override the English translation-string of Plone.
Hint: A translation for "Personal Information" occurs twice in plone.pot, you need to regard two message-ids.
Related
I have a patch which I want to close and hide in my project without landing it myself or let others to land it later on. This patch is just obsolete.
Is there any way to close/delete/reject this? I think so, because on their website it says:
You can reject code if you don't like it.
You can use the "Abandon" option in the "Add Comment" section to close revisions you no longer intend to pursue.
Use the "Abandon" option in the "Add comment" section at the bottom of the page.
So, I'm working on a site right now in Drupal that has a block designed to allow a visitor to jump to different "projects" (just a term). Most of the projects have content associated with them. However, some projects become empty from time to time as content is moved around and projects are restructured.
I currently have a view in place that shows an exposed form listing all of these projects as a dropdown and displaying it in a block. Is there a way for me to customize this view to only show projects that have content associated with them?
This would preferably be done entirely with the view. However, I would love to see any solutions you all can come up with. Also, please excuse my terminology if any is incorrect. I'm very new to Drupal and still getting used to the labels and structure of the whole CMS.
Any help would be greatly appreciated. Thx S/O!
Try this:
Edit the view. Under the Advanced section => Relationships, click add.
Add the relationship "Taxonomy term: content with term", and make sure to check "Require this relationship".
If this makes your view full of duplicates, try this answer to a question at drupal.stackexchange.com.
Hope that helps!
My client wants their site to be localised, so that example.com/uk presents the uk version, example.com/aus would be the australian version etc etc. However, I want the actual content, and the nodes delivered, to remain and the basic path structure to not change- just prefixed with the country code. Of course I want a 'switch country' button, automatic redirections based on geoIP etc, but for now I just want to focus on the path structure. However, I still want the country selected to be available within views, content types, template files etc, so that uk/products/chairs and aus/products/chairs will still be aliases of node/1 but will then be supplied with a session/cookie/variable set as 'uk' or 'aus'.
Does anyone know any way of doing this please? Google hasn't really supplied much knowledge :/
Many fanks! :)
If you're on Drupal 7, just go to admin/config/regional/language and click "edit" for each language which will allow you to set the "Path prefix language code." This will append the phrase of your choosing after the domain and before the Drupal path just as you requested.
The "Switch country" button can be found on the Blocks page as the "Language switcher" block.
As for uk/products/chairs and aus/products/chairs, so long as one is a translation of the other (using the built-in locale module and possibly the internationalization module, you shouldn't have any problems.
I am using Drupal 6 and I got a lot of pages and content.
To save time, is there a way to use a page Administrative title as the title that is used in the browser (the HTML title tag: <title>)?
Thankful for all input!
Perhaps the Page Title module may be of some help to you. It allows for more control of the html title tag by setting up title patterns using tokens made available through the Token module
Drupal does this by default (at least on my install it is currently) - are you building these administration pages yourself or are they the default ones?
Is it good for user experience to duplicate browser/keyboard functionality?
For example: to provide these links on a web-page.
"Back to top" link
"Print this page" link
"Add to Favorite" link
"Back" button/link
"Text zoom" button alt text http://shup.com/Shup/344995/110421205515-My-Desktop.png
Are they really create Site's usability and accessibility?
How screen reader will behave these links, will these confuse to screen reader users?
Many people haven't gotten into the habit of using the Home and End keys to go to the top and bottom of the page, so I don't find Back to Top links highly objectionable.
Print this page links can present a printer-friendly page, instead of the main page which is generally littered with banners and other stuff.
Add to favorites - Not a big fan.
Back button - Can be useful in workflow scenarios, but it better do exactly the same thing that the back button in my browser does. Generally the more common pattern is to provide a link, with describing text, such as "Return to Main Page."
Text Zoom Button - Love it. It allows me to tweak one site, while retaining the settings in my browser for other sites.
As a screen reader user I don't really care one way or the other. Listening to a couple extra links doesn't make a difference to me. Screen reader users are generally going to be a very small minority of the visitors to a site. If adding links such as top of page or add to favorites makes the site more usable to non screen reader users I would say add the links since it is something that's very easy for screen reader users to ignore. If you are writing a site specifically targeted at screen reader users then you may not want to add the links since they would be the majority of your users.
Adding such links should be motivated by a scenario. If users normally would print the page at a certain stage of the workflow when visiting your page, then it will be much more convenient for most of the users if the specific command option is directly visible and can be executed with a single-click.
Scenario: A user wants to buy an online ticket. They will select the event, choose a category, enter their personal details and billing information the finally will print the ticket. Instead of leaving the user alone at this last step and make him search the browser menus simply offer the print option inline in the body of the page.
I would say it was generally a very bad idea; the screen reader would definitely include ways of accessing the browser's implementation of that functionality, and duplicating that just wastes their time.
I would say that boilerplate-text is almost always bad for screen reader users.