I'm internationalizing strings in an application. It has a few places in the settings where added text is place in parentheses to indicate an informative "aside"
For example, the user can select an icon to appear on reports. There is a button for browsing along with the following additional text
(appears on reports)
Or sometimes I want to show that a value could not be known but I want to indicate that it's actually not known as opposed to it's value being the literal text "unknown". So I will put it in parentheses
(unknown)
In both cases I've used parentheses to indicate this. How do my parentheses translate to other languages and cultures? Is there some other, better internationalization mechanism for indicating these situations?
If you're writing an English-only application then it doesn't matter, just be consistent and most people would get it.
For localized applications the best practice is to decouple user facing strings from code to give your translators and editors flexibility to decide what to use.
So if your have string "Icon (appears on reports)" then consider a few options:
<span>{{ _t('Icon') }} {{ _t('(appears on reports)') }}</span> // troubles expected
<span>{{ _t('Icon (appears on reports)') }}</span> // okay
<span>{{ _t('icon_appears_on_reports') }}</span> // the best practice
In this way English editor and translators would be able to decide, for example:
EN: "Icon (appears on reports)" or "Icon, appears on reports" etc
RU: "Знак для отображения в отчетах"
Related
I'm developing logs viewer web program with Vue.js
I receive log data with ajax and display it with Slickgrid.
What i need to do is highlighting keyword after searching.
I found some examples highlighting whole cells or row but couldn't find highlighting specific keyword in cell.
ex)When i search a word 'cat', slickgrid shows cells which include 'cat'.
And i need to highlight the word 'cat' in the cell.
Anyone knows how to do this? or any examples??
Thank you.
You'll need to write a custom formatter. See here for an example page. Make sure you're using the 6pac repo - it's up to date, the MLeibman repo is unmaintained now.
Re highlighting a word, you'll need to return HTML from the formatter, and just have a special span to hilight the word, eg:
we will build a <span class="hilight">wall<span/>
It's a tricky business finding a full word, that is making sure it's not part of another word, if that's what you want eg.
did you buy the <span class="hilight">wall<span/>paper yet?
That's a whole 'nother Google search in itself.
I want to allow authors to enter long descriptions in the CKEditor image plug-in dialog, descriptions which then are available to screen readers via the aria-describedby attribute. In our use case, authors work in a WYSIWYG mode; they're not expected to edit raw HTML, so we can't ask them to enter an ID in the image dialog, add a corresponding ID to some other element, etc.
It's a trivial matter to enhance the CKEditor image plug-in dialog to have a field where the author can enter a long description to accompany the short alt description. The result could be something like <img data-long-description="this is a long description" alt="short description" />. But what we need is <img aria-describedby="longDescriptionID" alt="short description" />, where longDescriptionID is the ID of some element on the page (hidden from sighted users or not)....
I have a couple of possibilities in mind. (1) keep the image plug-in doing what it does: output an <img /> tag, as in the first example, and then some other code in the end user-facing view has the responsibility to find data-long-descriptions, replace them with IDs (randomly generated, say) in an aria-describedby attribute, and somewhere in the view insert corresponding content hidden from visual users, so that screen readers will pick it up.
Possibility (2) is to have the image plug-in output something like <span class="accessibleImage"><img aria-describedby="randomID1" alt="short description" /><span id="randomID1" class="accessibleLongDescription">This is nice, long description of the image blah blah blah</span></span>, where .accessibleLongDescription is hidden except to screen readers.
It's good that you're looking into this. More detailed descriptions for images are often useful. A couple of thoughts...
It isn't just people who use screen readers that find longer descriptions useful. People with cognitive disabilities will often benefit from more detailed explanations of complex images. If you can make the descriptions available on demand to anyone, this will help more people.
When the description is inserted into the DOM it needs to be immediately after the image it relates to. Screen readers use a translation of the DOM known as the accessibility tree to access content, so DOM order is important.
So one possibility is to combine your methods - search/replace the data attribute as you suggest in your first method, then insert the description based on the pattern in your second method.
Another possibility might be to use a disclosure widget pattern instead. Represent the image as the trigger control for the disclosure, and make the detailed description available when the widget is expanded.
A reasonable disclosure widget pattern is here.
I have three buttons which have the text 'select'.
Can I write the code to interact with these select buttons? They don't have any ids or name.
I am placing two of my buttons here:
<button class="btn btn-default ng-scope" type="button" data-ng-click="onBtnSelectClicked(coverage)" translate="l_choose">Select</button>
<button class="btn btn-default ng-scope" type="button" data-ng-click="onBtnSelectClicked(coverage)" translate="l_choose">Select</button>
If you tell me some other way to interact this button that's fine too.
EDIT
I have found an answer to this question, here is the answer
b.buttons(:text,'Select')[1].click
I beg to differ from above Comments. When in UI testing we Very routinely come upon such scnearios for rich applications. [Angular/Dojo etc]
It is also possible they put intentionally vague properties so that the user can dynamically re arrange and or increase decrease frames/panels as he needs. I've had huge arguements with dev guys on this part - evn now it does not make much sense to me how much ever they explain.
Consider this - you may want to open up some kind of doc and compare side by side and you have same elements in two frames - so lets say opnen a frame and split it into two and say compare / find / select etc etc may be some of the common objects that someone can design.
So I am guessing - if in any case the dev has intentionally decided to go with same properties - the parent or any ancestor should DEFINITIVELY differ. So you need to narrow that down and go for it. This IS the right approach since your tests wont break unless intent/functionality is updated specifically.
if not then this is a poor application design, you may possibly let dev know for some text differentiation.
When editing in ckeditor I very frequently end up with extra clusters of <p> </p> tags. Not only does it add extra unneeded linebreaks, they often show up on the resulting page with a broken-looking character in them.
Is there a configuration setting or something to tell the editor not to add these extra non-breaking spaces in paragraph tags?
Thanks,
doug
The paragraphs with represent empty lines in editor. They make the content look exactly the same inside editor and outside it (when displayed on a target page). If they cause you some problem, then it's not the editor, but your backend. So I rather recommend checking it.
Surprisingly though, there's an option to disable filling empty blocks config.fillEmptyBlocks.
But it's really not the answer.
I don't find the oft-used "*" to be very nice looking - can anyone suggest a nicer-looking method or point me to an example?
I tried making the field highlighted in red as one person suggested but I did not like the look.
Bold labels might do the trick.
But I really like the idea of "Required" being shown in grey in the field until text is added. Does anyone have code for this?
Generally speaking, the best web forms are the simplest ones that require me to think the least. The "standard" that has evolved is that required fields have an asterisk (*) next to them. Sometimes the asterisk is red to help it stand out a bit.
Why fight the standard? Don't make your users think too much. Go with the standard and keep your creativity for more important things.
If you're going to use colour to highlight the field, bear in mind that some people are colour-blind (so maybe provide another indicator too)
If you use stylesheets to format your HTML, then you can create a style for .mandatory. As an example, set the mandatory input to use this style, then you can play with it more easily until you have the right mix of color, border, and other style elements to suit your overall design.
HTML
<input id="username" type="text" class="mandatory" />
CSS
.mandatory {
color: red;
font-size: 12pt;
font-weight: bold;
font-style: italic;
}
I also use the asterisk as the OP mentioned as a "backup".
-R
Sometimes it really is justifiable to mark fields as mandatory and optional. However, before you do so, you should question whether it is reasonable to ask the user any non-mandatory information. This applies especially in registration forms.
In registration forms and such, it is much better to ask only the minimum information. After the registration the user can, at will, fill out optional information in separate forms.
After all the unnecessary cruft has been taken out from the form, you might see that there is no need to mark fields as mandatory; either everything is mandatory, or it might be so obvious to the user which fields are optional, that there would be no need to give visual cues about it.
add style="border: thin red solid;" to the element
I've found the answers on LukeW.com to be the most useful. because there isn't a simple solution here. It depends on what percentage of the fields are required, how many fields are in your form, and how long your labels are. For the vast majority of the web, people understand bold to be required, and normal-weight to be optional (if any options are bolded). Only after form validation fails would I present the user with the required-yet-skipped input boxes highlighted.
I typically have no objections to seeing (required) in a smaller font either right below the field name or adjacent to the entry field.
I could also see using a "textbox watermark" to have the field say "required" in it until they bring focus to the field and start typing.
I like the way it is done in the ASP.NET Ajax Control Toolkit for the ValidatorCallout control:
Might want to check out www.PeterBlum.com - His Professional Validation Package rocks for validating and formatting of controls. He has tutorials for using and numerous examples as well as a detailed manual.