Should it be
The page could not be found
or
The page could not be found.
?
With proper Oxford English the later would be the obvious choice but there are many examples for the first one out there as well.
What does your company's coding standard outline? Generally, this is the kind of thing a coding standard or business practice should address. There is no "right" choice.
That being said, obviously, the second one with the period. I base this on nothing but my personal preference.
Related
When there is a ready to use translator plugin available from companies like microsoft,google and yahoo why one has to implement globalization feature in an application using resource files like .resx. Why not simply plugin any one of those translator in the application and give the user with the freedom of choosing his own language/culture? Which one is better over other? Thanks in advance.
Automated machine translation is not the same as providing customized translations for different languages. Machine translation gets things wrong far too often, and can easily phrase something in a way that is offensive or embarrassing. It also doesn't take into account localization at all.
And more importantly, public machine translation services only work on public sites. Most globalized sites have pages only signed in users can reach. In that case, it is easier to provide translations yourself.
If you're making money off your customers, you're better off investing in real translation over a free service that ultimately marginalizes any users who don't speak the primary language the site is written in.
As I understand, these translators aren't as accurate. My last boss hired a translator and we translated the data into a separate language database table.
Autotranslate is not efficient and WILL get you in trouble when serious application is regarded. There is a very simple linguistic test you can perform on your application. First you translate from the original language to the target language. Then, you take the result and translate it back. If you get satisfactory results, you're good to go.
In fact, for some simple applications, that would be a recommended way. However, it MIGHT come back and bite you in the buttocks.
This is somehow subjective depending on the target translation language, but bear with me for a sec.
I have recently been involved in a translation project. The goal was to translate the strings of an MVC framework to the Greek language.
70% of the language strings of the framework where translated, however 30% where intentionally left out. The decision was that we will not translate error messages aimed towards the developer of the application.
The reasoning behind this (in short) was:
are aimed towards designers/programmers.
Programmers ( and even designers :) ) should have a basic
understanding of English, at least enough so
they can search on it on Google if
they do not know what it means. (racist?)
are aimed towards the developer
and in a perfect world should not be
displayed to the end user of the
application as they concern the
inner workings of the web
application itself. i.e "You must
set the database name in your
database config file."
and perhaps most importantly,
they make the life of the developer
harder when he tries to get more
information/help regarding the
error. For example the above error
yields 8 results in Google (in
quotes), whereas its Greek
translation yields exactly 0.
I know that this depends on the popularity of the target translation language and the application itself. For example I'm guessing that there are is vast amount of documentation regarding German SAP error messages (i know, i know, SAP IS German, but you get the point), as opposed to Greek Error Messages documentation regarding random application X which has about 500 installations worldwide.
So to summarize: When you develop language translation packs for your applications do you translate error messages? Do you only do for predominant languages like English/Spanish/German/French? Or do you leave them intact? I'm not looking for the "right" or "correct" answer, I'm looking for a "best-practices" answer, or if this problem is defined in any "official" standard/policy that you have had experience with.
A good framework that includes built-in error messages should have an option to i18n them. This is important entirely for the user.
Exceptions messages on the other hand must not be translated. You already pointed out an important reason - searching. And yes, they are for developers, not end-users.
If an exception message is also used as a display message to the user, this is wrong design. Exceptions may contain i18n keys.
Translated or not, make sure to always use a unique ID and allow the user to copy it.
TIP: in some applications, hitting Ctrl+C makes a copy of the message without being editable, would be nice to implement the same hidden feature.
I can only offer my own opinion, but for me as a German developer it's always annoying to get translated error messages, especially for widely spread software such as MS software. That's for two reasons:
German error messages are usually more difficult to understand because the German language makes everything sound more complicated. Also, there are often no good translations for IT-related words. German Developers either have to use English words instead or replace them with cumbersome literal translations. Same goes for MSDN websites, BTW.
Also, as you already mentioned, it makes it much harder to find solutions to those erorrs with google on English websites. The German developer community is much smaller than the English community...
If the application is for common business or consumer users and the error messages are displayed to them so that they can understand or take some action based on that then I believe it should be translated. If the error messages are purely for logging and troubleshooting then translation should be unnecessary.
What about printing them in both languages? The user/local admin knows what is going on and can search it and communicate with the developers.
Do not translate exception messages; It might turn to a translation nightmare.
I'm working a lot with Microsoft Office automation. Exception messages that were translated to Hebrew give me a real hard time:
Most of them I can't find on Google/MSDN, so I have to translate them back to English myself just for the sake of googleing it.
Some of them refer to objects by their translated class names. The object classes I'm manipulating (as a programmer) are always named in English. This just makes the messages less understandable.
Some of them are formatted strings, where the message itself is translated but the arguments constructing the message are not; this makes the message even less understandable, and sometimes it means the message won't display properly in a default MsgBox (Right-To-Left languages can be a nightmare).
From my experience, a developer needs his Exception messages in English, so translating those will simply require more effort on both sides, and will not gain you much.
There are typically a lot of error messages, and they are typically shown only sporadically. Therefore, translating them sometimes seems too much effort.
Depends on the app. A highly technical application that will be used by people that understand English and the target language, you might be OK with English error messages.
If it's a message that will be seen by the end user, it should be translated. Think about if you were using an application that was written by a Japanese developer and you saw an error message in Japanese. That's probably not going to be all that helpful to you -- you won't have any idea what it says, whether or not you could do anything about it.
Which one is better and ideal in a web based application?
Edit:
Actually I am developing a community site. So the level of users may vary. Heard about XSS security issues with WYSIWYG editors. Also I am not familiar with WYSIWYM editors and its features. As far as I know the features in WYSIWYM editor is less compared to the other one. I figured one named as "WMD: The Wysiwym Markdown Editor". Its quite easy to use.
So security and ease of usability should be there. In such a situation which editor will be better.
If your users can handle WYSIWYM, I'd go with that.
I'm considering your system will be visual, that is, if you say something is a title it'll look like a title (otherwise the WYS part wouldn't apply). If the user has to manually type markup, then only the most savvy or technical users will be able to handle it.
What I've seen with most users is that they have trouble giving meaning to what they want in a document. They don't think "this is a title", they think "this should be bigger and bold". People that cannot think "this is a title" can't handle a WYSIWYM or they'll find it hard.
Who is going to be your user base? If it's people writing academic papers I'd go with WYSIWYM because they'll have no trouble handling it. If it's for house wives writing recipes, they may not be able to handle it or they'll find it so hard that they'll decide it's not worth the effort.
For me the ideal is WYSIWYM, but do it only if you think your target users will be able to handle it, otherwise you'll have to go with WYSIWYG.
I personally love the WYSIWYM mechanism. I use it for my own work as much as possible. I like it so much that I try to get others to try it too.
Boy, that goes over like a fart in a space-suit.
My cynical self assumes this to mean that most folks are ruined by tools like Word. Everyone knows to make a meaningful document. They also know what a meaningful document looks like. If it doesn't look like that, the tool is wrong! What's actually happening is these document producers don't actually know what they mean, and are used to hiding that fact with pretty borders and adjusting tab-stops.
What I really think is happening, though, is that these folks who are resistant to WYSIWYM are that way because it's a harder way of thinking about something they already invested in learning. This is a level of abstraction above WYSIWYG, though not quite as far removed as composing documents in markup like LaTeX or HTML. And since they can already create any sort of document in a tool that requires no abstraction, it's just a hard sell.
That being said, I think you should force WYSIWYM on your users if that is feasable. There are some good reasons for this
All of the benefits that naturally come with two stage composition. Formatting is not decidable until the document is composed, so any time spent before the document is finished on formatting is time wasted. Get it composed quickly.
The document is marked up with semantic information. This can be used in searches, or for other tasks that strictly visual markup cannot. This is especially useful for accessibility.
By depriving your users of arbitrary formatting decisions, all of your documents will follow company branding. Everything will be in a standard font and color. All text will use the same spacing and height. It will look to readers like it came from a single entity.
Check this
http://www.wymeditor.org/
Could you be a bit more specific? What kind of web application? How many users? Who will the users be?
In general though I've had quite of bit of experience implementing WYSIWYG editors for various CMSs and found them to be quite problematic because clients often like to go wild with formatting their content repeatedly over and over again and often end up having the editor generate HTML of poor quality. This causes all sorts of layout issues or simply pages that look really messy because everyone likes to fancy themselves as graphic designers.
If done properly WYSIWYG can work very well, but it is more work to really get it right, especially when taking into consideration CSS. Most of the good editors are nicely configurable and allow to specify just how much control to give the client over visual formatting.
As for the quality of the code they generate, tools such as FCKEditor and TinyMCE are very mature and do a good job of editing out the irrelevant crud in the source code, but be prepared to provide support for clients using a WYSIWYG when their content doesn't look the way they would like it to.
Since WYSIWYM editors are much like WYSIWYG with structural formatting instead of visual formatting, philosophically I think they are better and less problem prone. So if the client doesn't have a need to visually format the content I think WYSIWYM is bound to cause less headaches down the road.
The editor used here in Stack Overflow is a good example of restrained WYSIWYG. You can format the content visually but only to a certain extent.
If your users a tech savy and understand how the basics of markup go and you think they will feel more empowered using WYSIWYM, then use that. If your application is going to be used to people who have little technical knowledge, use WYSIWYG.
Unless you are doing a tool for print layout (i.e. Indesign or maybe a mailing list printing tool) you are probably better to stick with WYSIWYM.
It is likely to be easier to implement
Web browsers are highly configurable and you may not have fine grained control over items like font size.
The structure is explicit so rendering to different media is comparatively easy.
It avoids the temptation on the part of users to over-design the document or whatever they are entering.
Document structure facilitates indexing, table-of-contents generation and cross-referencing where this is relevant. Compare (for example) maintianing a large index in Word with doing in LaTeX or Framemaker.
Anecdotal experience from LaTeX users (in particular) suggests that organising a document by structure is likely to produce a better document.
From my experience with MYSIWYM, I was very seduced by the idea and the looks, but I was then deceived to know that the editor didn't give me a simple and efficient way to restrict the user, for example the user can insert images inside paragraphs... and I don't want that... I want more control over what the user can do.
I'm working on a "twitter filter" - more to learn ruby on rails than anything else. The idea is that I use a semantic ontology to lookup a users interests. So if a user says they're interested in "sports" that means flag any tweets that discuss "sports" "golf" "football" and so on.
I'd like to be able to expand it to any hierachial of topics, though. So if you're interested in Europe flag all the countries in Europe.
Naturally this is rather complex, so maybe we'd limit it to one or two "levels" of lookup...
How could I do this efficently? I'm pretty familiar with Java, C and Ruby, and have worked a lot with MySQL.
I'd look into Doug Lenat's Cyc. It's done and open.
I'm not sure if it will help you, but Google has something called Google Sets. You can look on it here: http://labs.google.com/sets
Before you think about programming languages and technology, think about this: What kind of datastructure is a "semantic onthology"?
To me that sounds like some kind of a directed graph.
Knowing that, you'll soon find out, that it's quite easy to implement such a structure in whatever language and technology you want and that a lot of languages already have implemented some kind of a graph library (e.g. RGL for Ruby).
To me the real problem isn't how to implement such a datastructure and how to do this efficiently but how to get the semantic information you need out of twitter to build this (e.g. who tells your application that europe isn't a part of spain but that spain is a part of europe?).
Anyway, have fun implementing it, sounds like a cool project! :-)
I'm not sure what your requirements are. But it seems that either Singular Value Decomposition (SVD) or Support Vector Machines (SVM) will work for you.
What is the current state of the art in rails for preventing spam accounts? Captcha? Any good plugins, tutorials or suggestions?
Use a library: You're (almost) always better off appropriating code from people who are better at the subdomain than you are. The Wordpress guys behind Akismet have forgotten more about blog spam than I know, and I was an email anti-spam researcher for a while. You might be interested in a Rails integration plugin for Akismet.
Defense in Diversity: Spam is a quirky problem, in that the more popular a countermeasure gets the worse it becomes. As such, particularly for low-profile sites, you can get disgustingly good results by coding simple one-off tripwires. I won't give you any code to copy/paste because it defeats the purpose of the excercize: having a countermeasure which is globally unique.
One simple example is having a hidden form element which starts as some randomized string, and which is set to a known good value by Javascript code. You then bounce anything which doesn't have the good value supplied. This blocks clients which don't implement Javascript, which includes the overwhelming majority of spam scripts. There are issues, of course, as some legitimate clients also block Javascript -- but realistically, if you're using Rails, I'm guessing you're sort of assuming cookies are on and Javascript works.
I also recommend ReCAPTCHA, both because it's a highly-reliable service you don't have to manage, and because it serves two common goods - the OCR tasks described by the ReCAPTCHA team, and the progress towards teaching people how captchas work, reducing abandonment rates.
Edit:
It appears BranBuster is dead (this was years ago). But I really like:
https://github.com/matthutchinson/acts_as_textcaptcha
I'm a big fan of the rails plugin called "BrainBuster". It's a logic-based CAPTCHA which I find preferable over the "type these words" things, because it is annoying to decipher the words sometimes... It's simple to look at "What is 10 minus 3?" and come up with the answer. YMMV:
https://github.com/rsanheim/brain_buster
There is a re-captcha plugin if you want to use captch to verifye that only human can register, or add content: http://ambethia.com/recaptcha/files/README_rdoc.html
Spam is fair. It doesn't care what you're running behind the scenes.
So by extension, the things that work well on Rails are the same things that work for PHP, ASPNET, etc. Take a look at Akismet and the various "karma" anti-bot tools there are about.
For some there are existing ruby ports but you might have to rewrite a few to task.
For account creation, you may want to use Captchas. I personally am not terribly fond of them and I don't think they are that effective. But if you use them, I strongly suggest you use a service instead of trying to whip up your own. Re-captcha comes to mind. Not sure if there are wrappers for Ruby or Rails, though.
To prevent spam content, however, I strongly suggest Defensio (disclaimer: I've worked there in the past). It uses state of the art spam filtering techniques like what's used for email, such as bayesian filtering. There are plugins for many blogging platforms, including Mephisto (made with Rails). The API is simple and you can look in a few places to get working examples of how to use it with Ruby.