StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
6452824
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
1
CommunityOwnedDate
CreationDate
2011-06-23T10:49:11.053
FavoriteCount
0
LastActivityDate
2011-06-23T10:49:11.053
LastEditDate
2017-04-12T07:31:21.413
LastEditorUserId
-1
OwnerUserId
247221
ParentId
6448451
PostTypeId
2
Score
18
ViewCount
0
LastEditorDisplayName
text
Body
There are a lot of things that need to be taken care of while internationalizing application: Locale detection The very first thing you need to think about is to detect end-user's Locale. Depending on what you want to support it might be easy or a bit complicated. <ol> <li>As you surely know, web browsers tend to send end-user's preferred language via HTTP Accept-Language header. Accessing this information in the Servlet might be as simple as calling <code>request.getLocale()</code>. If you are not planning to support any fancy <a href="https://softwareengineering.stackexchange.com/q/15050/2554">Locale Detection workflow</a>, you might just stick to this method.</li> <li>If you have User Profiles in your application, you might want to add Preferred Language and Preferred Formatting Locale to it. In such case you would need to switch Locale after user logs in.</li> <li>You might want to support URL-based language switching (for example: <a href="http://deutsch.example.com/" rel="nofollow noreferrer">http://deutsch.example.com/</a> or <a href="http://example.com?lang=de" rel="nofollow noreferrer">http://example.com?lang=de</a>). You would need to set valid Locale based on URL information - this could be done in various ways (i.e. URL Filter).</li> <li>You might want to support language switching (selecting it from drop-down menu, or something), however I would not recommend it (unless it is combined with point 3).</li> </ol> JSTL approach could be sufficient if you just want to support first method or if you are not planning to add any additional dependencies (like Spring Framework). While we are at Spring Framework it has quite a few nice features that you can use both to detect Locale (like <a href="http://static.springsource.org/spring/docs/1.2.x/api/org/springframework/web/servlet/i18n/CookieLocaleResolver.html" rel="nofollow noreferrer">CookieLocaleResolver</a>, <a href="http://static.springsource.org/spring/docs/1.2.x/api/org/springframework/web/servlet/i18n/AcceptHeaderLocaleResolver.html" rel="nofollow noreferrer">AcceptHeaderLocaleResolver</a>, <a href="http://static.springsource.org/spring/docs/1.2.x/api/org/springframework/web/servlet/i18n/SessionLocaleResolver.html" rel="nofollow noreferrer">SessionLocaleResolver</a> and <a href="http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/web/servlet/i18n/LocaleChangeInterceptor.html" rel="nofollow noreferrer">LocaleChangeInterceptor</a>) and externalizing strings and formatting messages (see <a href="http://static.springsource.org/spring/docs/1.2.x/taglib/tag/MessageTag.html" rel="nofollow noreferrer">spring:message tab</a>). Spring Framework would allow you to quite easily implement all the scenarios above and that is why I prefer it. String externalization This is something that should be easy, right? Well, mostly it is - just use appropriate tag. The only problem you might face is when it comes to externalizing client-side (JavaScript) texts. There are several possible approaches, but let me mention these two: <ol> <li>Have each JSP written array of translated strings (with message tag) and simply access that array in client code. This is easier approach but less maintainable - you would need to actually write valid strings from valid pages (the ones that actually reference your client-side scripts). I have done that before and believe me, this is not something you want to do in large application (but it is probably the best solution for small one).</li> <li>Another approach may sound hard in principle but it is actually way easier to handle in the future. The idea is to centralize strings on client side (move them to some common JavaScript file). After that you would need to implement your own Servlet that will return this script upon request - the contents should be translated. You won't be able to use JSTL here, you would need to get strings from Resource Bundles directly. It is much easier to maintain, because you would have one, central point to add translatable strings.</li> </ol> Concatenations I hate to say that, but concatenations are really painful from Localizability perspective. They are very common and most people don't realize it. So what is concatenation then? On the principle, each English sentence need to be translated to target language. The problem is, it happens many times that correctly translated message uses different word order than its English counterpart (so English "Security policy" is translated to Polish "Polityka bezpieczeństwa" - "policy" is "polityka" - the order is different). OK, but how it is related to software? In web application you could concatenate Strings like this: <pre><code>String securityPolicy = "Security " + "policy"; </code></pre> or like this: <pre><code>Security policy </code></pre> Both would be problematic. In the first case you would need to use <code>MessageFormat.format()</code> method and externalize strings as (for example) <code>"Security {0}"</code> and <code>"policy"</code>, in the latter you would externalize the contents of the whole paragraph (p tag), including span tag. I know that this is painful for translators but there is really no better way. Sometimes you have to use dynamic content in your paragraph - JSTL fmt:format tag will help you here as well (it works lime MessageFormat on the backend side). Layouts In localized application, it often happens that translated strings are way longer than English ones. The result could look very ugly. Somehow, you would need to fix styles. There are again two approaches: <ol> <li>Fix issues as they happen by adjusting common styles (and pray that it won't break other languages). This is very painful to maintain.</li> <li>Implement CSS Localization Mechanism. The mechanism I am talking about should serve default, language-independent CSS file and per-language overrides. The idea is to have override CSS file for each language, so that you can adjust layouts on-demand (just for one language). In order to do that, default CSS file, as well as JSP pages must not contain <code>!important</code> keyword next to any style definitions. If you really have to use it, move them to language-based en.css - this would allow other languages to modify them.</li> </ol> Culture specific issues Avoid using graphics, colors and sounds that might be specific for western culture. If you really need it, please provide means of Localization. Avoid direction-sensitive graphics (as this would be a problem when you try to localize to say Arabic or Hebrew). Also, do not assume that whole world is using the same numbers (i.e. not true for Arabic). Dates and time zones Handling dates in times in Java is to say the least not easy. If you are not going to support anything else than Gregorian Calendar, you could stick to built-in Date and Calendar classes. You can use JSTL fmt:timeZone, fmt:formatDate and fmt:parseDate to correctly set time zone, format and parse date in JSP. I strongly suggest to use fmt:formatDate like this: <pre><code><fmt:formatDate value="${someController.somedate}" timeZone="${someController.detectedTimeZone}" dateStyle="default" timeStyle="default" /> </code></pre> It is important to covert date and time to valid (end user's) time zone. Also it is quite important to convert it to easily understandable format - that is why I recommend default formatting style. BTW. Time zone detection is not something easy, as web browsers are not so nice to send anything. Instead, you can either add preferred time zone field to User preferences (if you have one) or get current time zone offset from web browser via client side script (see <a href="http://www.w3schools.com/jsref/jsref_obj_date.asp" rel="nofollow noreferrer">Date object's methods</a>) Numbers and currencies Numbers as well as currencies should be converted to local format. It is done in the similar way to formatting dates (parsing is also done similarly): <pre><code><fmt:formatNumber value="1.21" type="currency"/> </code></pre> Compound messages You already have been warned not to concatenate strings. Instead you would probably use <code>MessgageFormat</code>. However, I must state that you should minimize use of compound messages. That is just because target grammar rules are quite commonly different, so translators might need not only to re-order the sentence (this would be resolved by using placeholders and <code>MessageFormat.format()</code>), but translate the whole sentence in different way based on what will be substituted. Let me give you some examples: <pre><code>// Multiple plural forms English: 4 viruses found. Polish: Znaleziono 4 wirusy. **OR** Znaleziono 5 wirusów. // Conjugation English: Program encountered incorrect character | Application encountered incorrect character. Polish: Program napotkał nieznaną literę | Aplikacja napotkała nieznaną literę. </code></pre> Character encoding If you are planning to Localize into languages that does not support ISO 8859-1 code page, you would need to support Unicode - the best way is to set page encoding to UTF-8. I have seen people doing it like this: <pre><code><%@ page contentType="text/html; charset=UTF-8" %> </code></pre> I must warn you: this is not enough. You actually need this declaration: <pre><code><%@page pageEncoding="UTF-8" %> </code></pre> Also, you would still need to declare encoding in the page header, just to be on the safe side: <pre><code><META http-equiv="Content-Type" content="text/html;charset=UTF-8"> </code></pre> The list I gave you is not exhaustive but this is good starting point. Good luck :) 
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POJava web application i18n
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USCommunity
UserOwnerUserId
1. USPaweł Dyda
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POJava web application i18n
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. COThanks for the excellent answer. Unfortunately, the application I'm using is mammoth (it's a very old project). Spring was introduced sometime into the project (which is ~10 years iirc) and I am using Spring's i18n support in part of the application making use of strings. Unfortunately, it doesn't seem that anyone has really thought of i18n so it appears that I'm stuck with a rather long and tedious task...
 singulars
 PostPostId
 PO
 UserUserId
 USNRaf

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.