tapestry5tapestry5
Localization (aka L10n) is all about getting the right text to the user, in the right language.
Localization support is well integrated into Tapestry. Tapestry allows you to easily separate the text you present to your users from the rest of your application ... pull it out of your Java code and even out of your component templates. You can then translate your messages into other languages and let Tapestry put everything together.
If the file WEB-INF/AppName.properties exists in the context, it will be used as an application-wide message catalog. The AppName is derived from the name of the filter inside the web.xml file; this is most often just "app", thus WEB-INF/app.properties. The search for the file is case sensitive. The properties files may be localized.
Individual pages and components can override the values defined in the message catalog.
Avoid BOMs
Make sure that your properties files don't contain byte order marks (BOM), because Java and thus Tapestry doesn't support BOM in properties files (see ?bug_id=4508058). Some editors write them out when saving a file in UTF-8, so watch out.
The above discusses what files to create and where to store them, but doesn't address how to make use of that information.
Messages can be accessed in one of two ways:
Using the "message:" binding expression in a component template
By injecting the component's Messages object
In the first case, you may use the message: binding prefix with component parameters, or with template expansions:
Here, the page-title message is extracted from the catalog and passed to the Border component's title parameter.
In addition, the greeting message is extracted and written into the response as part of the template.
As usual, "prop:" is the default binding prefix, thus user.name is a property path, not a message key.
You would extend this with a set of properties files:
Or, perhaps, a French version:
Programatically, you may inject your component message catalog into your class, as an instance of the Messages intece:
You could then get() messages, or format() them:
The format() option works using a java.util.Formatter, with all the printf-style loveliness you've come to expect:
As easy as conditionals are to use inside a Tapestry template, sometimes it's even easier to do it in Java code.
The PersistentLocale service can be used to programmatically override the locale. Note: You should be careful to only set the persistent locale to a supported locale.
Once a persistent locale is set, you will see the locale name as the first virtual folder in page render and component event requests URLs. In this way, a persistent locale will, in fact, persist from request to request, or in a user's bookmarks.
You will see the new locale take effect on the next request. If it is changed in a component event request (which is typical), the new locale will be used in the subsequent page render request.
Note that the locale for a page is fixed (it can't change once the page instance is created). In addition, a page may only be attached to a request once. In other words, if code in your page changes the persistent locale, you won't see a change to the page's locale (or localized messages) in that request.
Fortunately, Tapestry uses all the same mechanisms for its own locale support as it provides for your application. So, to support other locales, just translate the built-in message catalog (property) files yourself:
To have Tapestry use these new files, just put them in the corresponding package-named directory within your own app (for example, src/main/resources/org/apache/tapestry5/core.properties).
Finally, please open a new feature request here and attach the translated files so that they can be included in the next release of Tapestry.
本文来自电脑杂谈,转载请注明本文网址:
https://www.pc-fly.com/a/jisuanjixue/article-32013-1.html
祭奠为中华牺牲的士魂
于是俺们厂里买了好多跟废品差不多的浙商设备
没人希望战争