I'm developing a web application using Spring, JSF 2 and Primefaces 3. I want the user to be able to choose from different languages. I don't want to use Google Translate. Which is the best approach to translate my website?
Take a look at http://www.coreservlets.com/JSF-Tutorial/jsf2/#Properties
Basically, you create a properties file for each language, like messages.properties, messages_fr.properties, messages_es.properties etc. and the appropriate one is loaded according to the locale.
The user can also select the language herself, take a look at the next tutorials at that site to see how to implement it.
Are you asking how to implement this technically or how to get the content of your site translated?
For the former I trust you can find a guide or five.
For the latter if you don't want to use an automated service like Google Translate then you're going to need humans to do it for you. Unless you have multilingual friends who owe you a favor or, say, a giant, enthusiastic userbase like Facebook or Twitter has, you're not going to get this for free. Your options, basically, are to pay for the services of one of the many, many companies out there that do this, or find multilingual individuals on your own, e.g. by calling local universities' foreign language departments or international student organizations, or posting on Craigslist and the like. As with web development contractors, I think it's safe to assume you get what you pay for.
When you say you don't want to use Google Translate, do you men GT specifically, or any such service? Because if you're not using any translation service, you'll have to maintain versions of each page on your site in different languages. And maintain them.
Come to think of it, you probably have to take this approach as none of the online translation services provide a good enough native translation.
There's probably some commercial machine-translation packages out there, but they don't come cheap, I imagine.
Alternatively, employ an army of translators - there's websites out there where you can hire translators.
You'll probably want to do a search for translation software, then figure out how much it'd cost you.
Related
What is considered the best strategy for URLs of translated websites? Something I see happen frequently is:
http://example.com/english-slug.html
http://example.com/de/english-slug.html
http://example.com/fr/english-slug.html
This has the (minor) advantage that a user can manually switch to another language by modifying the URL. The disadvantage seems to be that the URL consists of a slug in the wrong language for every page not in the default language. That would cause a SEO penalty, I think.
The alternative would be to translate the slugs as well and optionally omit the language identifier as well:
http://example.com/english-slug.html
http://example.com/deutscher-slug.html
http://example.com/slug-francois.html
Some languages do not really lend themselves to be 'sluggified', such as Russian, Chinese and Arab. You'll end up with transliterations that make little sense.
I think you should use language tags and translated slugs:
http://example.com/en/hello-world
http://example.com/de/hallo-welt
Why language tags? To avoid collisions.
Sometimes you might want to have the same slug for different languages (for example, "team" in English as well as in German).
Why translated paths? For better usability.
Not all users understand the "default" language, and depending on its script, they might not even be able to type/remember/dictate the slug. (It doesn’t make sense in the first place to use human-readable slugs that only part of your users are able to understand.)
Yes, it would be a "(minor) advantage that a user can manually switch to another language by modifying the URL". But it’s unlikely that users or search engines would expect this to work (see my related answer on Webmasters). So you would gain little (URL hacking for advanced users) and lose much (bad usability for users using the non-default language).
That said, it would still be possible to enable this URL hacking feature in most cases: When users change the language tag de (in /de/hallo-welt) to en (/en/hallo-welt), you could check if it exists (if yes, show it), and if not, check if there exists a slug "hallo-welt" in any language, find its English translation and redirect to it (from /en/hallo-welt to /en/hello-world).
Another way is setting the language as a query string parameter, such as:
http://example.com/hello-world?hl=en
http://example.com/hallo-welt?hl=de
for example Google Flights web site uses this method.
The best solution, if you can afford it, is to send the document with the right name, that means, using the right word on each language.
Of course each document should be sent with the respective language setting on the headers.
For storing them, you can use folders and let the web server choose the right document according to the language preference; or you can use server side technology, like PHP, perl, etc to send the document and adjust the URL.
In any case, you have to have a default language to be sent when you don't have the requested language.
If you can't or don't want to send document with the right name, using subdomains is the best next option. This option, is not as common as adding the language after the domain, and that means, that people may not be used to it, although, it has some advantages, for instance;
Each language behaves like a whole new URL/site (almost).
People feel like visiting a dedicated site, not a subsection where the second language is relegated and may fail at any moment (some content may not be translated).
Some people are not familiar with their two letter representation of language, but everybody knows how his language is called and spelled.
It generates cleaner URL's.
It is believed that having subdomains increases appearance on SERPs (I don't have knowledge of this and it may have changed).
It's easier to have different layouts if you want to.
It's easier to set different servers according to language.
Of course subdomains have some disadvantages, like:
A bit more work to set properly from the server perspective.
Less collaboration from the part towards high ranking.
Some people may not expect it but expect a subfolder.
Next would be the subfolder option, as you show on the question. This is the recommended way if your main perspective is SEO since all the relevance of the domain stays on that same domain and each language helps to a common "pot" of ranking.
My perspective when choosing a solution, is never SEO, under any circumstance. Whatever ranking I get is due to the content itself and the best use I can give to technology. But I understand that my point ov view is not the most common.
One thing to consider also, is that you should provide some kind of explanation or help the user so he can take actions to change to the preferred language. It may be using icons, a tooltip, or any other method that works for your design and verbosity.
One thing to avoid, and you didn't ask for it, but is related; is using language autodetection. Lots of times, the user is in a different country or using a version of a browser that has a different language from what he can understand and the autodetction just makes a big mess. Offer the default version and a clear way to change it.
I am wondering if there is a standard pre-built web application for Rails which has all the basic functionalities like user login, user profiles, profile image uploader, comments, search, maybe payments and a set of other usual web application features all bundled and ready to use and extend.
I like how Twitter bootstrap comes with a set of pre-built interface functionalities and styles, which you can start using and modify later. I am looking for something similar that can allow me to quickly set up a working application and go from there.
Does such a framework exist?
There are numerous examples out there.
However, there are two things you should really do:
Read the license to make sure you can use it they way you are thinking of using it.
Ensure you understand the design decisions and choices the original authors made. You will end up in a world of maintenance pain if you just copy cargo-cult style without understanding the tradeoffs others have made with their design decisions.
Any one of the links listed has enough to get you started. They may not have all of the features you listed but together they probably have all of your bases covered. You will have to put in some effort to get all those features working together though.
The RailsApps project is great because they all have tutorials that walk through the basic setup. They are also all built using the Rails Composer tool, which lets you pick and choose certain options for your app.
My site requires authentication, so it has membership. I wonder if I should create my own comment system for user to discuss/comment on an article, or should just use third-party comment system like Disqus or Intense Debate, which requires seperate account (Twitter, Facebook, etc.).
In fact, it would be good if there is a guide to create my own comment system or Q&A system for users to discuss a particular article on my website. If you know of any, please lemme know.
Thanks.
I recently am working on a project where I had to weigh the same things. I eventually decided to roll my own comments.
Namely the advantage of rolling your own is that you have full control on how they work. I needed a moderation system/queue that I needed to work a specific way, for one. Second, someday I will be looking to integrate a 'community reputation' system, so that was another plus for rolling my own. Such things I don't want to leave to a third party solution outside of my control and the third parties don't always have such a flexible API to modify.
On the other hand, Disqus (or similar third party commenting systems) may be up your alley if your needs are more simple. For one, it's easy to get up and running and may be all you may really need. Accounts for it work across anything using Disqus, and that may win convenience points for your users who are sick and tired of having to sign up for a million accounts for a million websites. Disqus also has built in tools (for spam, trolls, etc) and that is also convenient.
If you go with rolling your own solution with user accounts, you can integrate things like Facebook/Twitter/etc login to make the registration process easier. But overall, like I said, depends on how fancy or complex you need the whole thing to be.
Should you roll your own, a good start is a recent Railscasts episode on the Ancestry gem http://railscasts.com/episodes/262-trees-with-ancestry, it should give you a good start on building threaded comments.
Something in the middle :) Use the acts_as_commentable plugin :
https://github.com/jinzhu/acts_as_commentable
I have a relatively simple site on my hands, and have for nearly a year, but I can't seem to find a platform to build it on that doesn't fight back at the way I want to do things. Here are the key features:
Customizable profiles. Profile tags.
Two primary content types: Haves & Wants
Both content types searchable/taggable and expire with a "Taken" symbol if user chooses.
Private messaging.
Daily cron attempts to find matches of Haves and Wants with similar tags and uses email alerts.
I think I can understand the logic of building this in Rails... but I'm too much of a noob to execute it. Is there a easier framework or cms out there that can produce something like this?
Additional information: We currently are using a modified version of the Classipress template for wordpress. It got us a little ways through development... but we can't seem to convince wordpress to post more than one type of content or tags. http://mybarterhub.com/
I wouldn't attempt something like this on Wordpress (not what it was designed for), but any of the frameworks you mention are more than capable. Have you looked at Drupal? I think it hits a sweet spot of allowing you to do a lot without actually programming, but also allowing programmers to customize it heavily through modules. It has a lot of the community and taxonomy features you need -- either built in or available through common modules.
If you're unable to get too deep into a framework like CakePHP, I would say Drupal is your best bet. Drupal is pretty non-coder friendly, but if you're going to make it work for projects that are more complex than out-of-the-box type situations, there's a slight learning curve.
There's at least one module that lets you use a custom Content Type for the user profile, which should allow you to tag profiles (the profile content type nodes) using the taxonomy module. Users in Drupal aren't nodes, so I'm guessing that's why tagging them wasn't working for you.
As for searches, all content should be indexed and searchable in Drupal as long as it's set up to do so. I'm not sure what modules are available for specifically searching by Taxonomy term, but, if you're using a tag system and you want to present haves/wants by tag, that's easy enough to set up with the wonderful Views module. A while ago I think I set up views that mirrored the taxonomy vocab/term structure and just redirected to the view using a Taxonomy Redirect module when someone clicked on a tag.
I think that if you can't make it work in Drupal for some reason (or you really don't like Drupal), you'd have to get into CakePHP or one of the other frameworks out there, but Drupal is definitely able to accomplish what you're aiming to do, probably without any custom PHP coding involved if you got all the right modules together.
I've been programming for years, and I've also done a few professional programming projects. I recently had a friend ask about creating an e-commerce site, but I had to turn her down because I had never worked on a web application that can bill. I also might need to write a subscription-based web service in the future. My question is, how do I even get started with billing? I've never found a guide about this, and I barely know how bank accounts work since I don't manage my own one (I have an excuse for this since I'm only 16).
I don't know if the answer is language dependent, but if it is the languages I'm interested in are Python, C/C++, and Java.
There are lots of ways to go about setting up e-commerce sites;
If you don't have any experience whatsoever, and don't want to get into anything "complicated", i would suggest going with a customizable web "storefront" hosted by someone else, pre-integrated with credit card processing, etc. There are tons of options for these online. Just search google for "web storefront". Yahoo! even has such a service:
http://smallbusiness.yahoo.com/ecommerce/sellonline.php
Going beyond that, It's pretty easy to integrate with someone like PayPal. They have all sorts of options from the most basic (use a link to send someone to their site with query string parameters to let paypal know what the user wanted to buy):
https://cms.paypal.com/us/cgi-bin/?&cmd=_render-content&content_ID=developer/home
Beyond that level, you will need to signup for a merchant account, or other similar sort of service, like the one offered by authorize.net (who I like):
http://www.authorize.net/
There are components you can buy for most major web development platforms like .NET, JSP, etc. Perfect example is dotnetcart. These components provide out-of-the-box, easy-to-setup integrations with major CC processing companies, as well as out-of-the-box shopping cart implementations:
http://www.dotnetcart.com/
Finally, most merchant services / payment gateways provide web services for direct integration.
PS.) Never ever ever store CC numbers ; )
I would look at paypal's api to get started. You might not want to stick with them but it is a good starting place to learn about dealing with credit card clearing houses and such.
Here ya go.
You'll typically interface with a 3rd-party for doing banking transactions. One that I've work with in the past is Authorize.Net but there's plenty out there (PayPal is another fairly popular one with a decent API).
Basically, the best approach is to do as little as possible and let the 3rd party handle all the "hard" stuff (such as security, managing credit card details and so on).