I create internationalization for my application and am wondering if I can create several files to create translated messages. I do not think it's advisable, but I prefer to ask.
The thing is that I have a 'messages.properties' file where I have some text already
http s://pastebin.com/WdyE0Aaj
And this is just the beginning. What if I will have dozens of pages and for each page I will have to declare here translation. After all, this file will go on in the hundreds and then thousands. Can it be somehow divided into more files?
Of course you can (and probably should, to keep things maintainable).
The Spring-boot reference says:
spring.messages.basename=messages # Comma-separated list of basenames, each following the ResourceBundle convention.
So, just add as many basenames as you want to your spring boot properties/yaml file, and they will all be agregated in a single MessageSource. Just make sure to avoid conflicts in the i18n property names.
Related
I want to put the configuration file of the log4j2 (v2.17.0) outside of the war file. Therefore, I can change the logging configuration without redeploying the war file. The log4j2-web.jar provides mechanism to configure the configuration file outside of the war file along with other features.
Unfortunately, I am not allowed to use the log4j-web.jar file in web application.
According to the log4j2 FAQ, it is not recommended to use LoggerContext to load configuration file because it is not part of the public API.
Question:
Is there any valid way to use log4j2 in the web application without log4j-web.jar file?
Question: Is there any valid way to use log4j2 in the web application without log4j-web.jar file?
There are two potential ways that you could dynamically update the logging configs without using log4j2-web.jar .
Ignore the FAQ's recommendation1 and use LoggerContext.reload to reload the configuration.
It is possible that the Log4j2 team could change something in a future version so that this approach no longer works. But this is unlikely (IMO) ... and you can deal with that problem if / when it happens.
Use Log4j2's automatic reconfiguration mechanism. Basically, you tell Log4j2 to regularly check the config file to see if it has changed.
However ...
If I was you, I would want to understand why you are "not allowed" to use "log4j-web.jar". Is it for security reasons? If it is, you may need to talk to the security people so that you fully understand the security reasons.
Q: Why?
A: Because you appear to be wanting to duplicate some of the functionality of "log4j-web.jar". It may be that it is the functionality you are trying to duplicate that is the root of your security team's concerns. And if that is the case, then implementing the functionality by hand (i.e. without using "log4j-web.jar") could potentially be worse ... from a security perspective!
So ... find out! This is NOT a case where "asking for forgiveness rather than for permission" is a sound strategy.
1 - Actually, I don't read this as a "recommendation". Rather, I read it as a "warning of potential consequences". If they really thought that using LoggerContext.reload this was a bad idea, I think they would have used more explicit language.
Anyone happen to come come across a use case where one has to stick to java.util.Properties.load method to read all the key-value pairs from a .properties file but at the same time to be environment/profile specific, placeholders, ${...} are used?
I'm building a spring boot app. and have profile specific properties files and placeholders work fine in them. However, the app. is dependent on a relatively older app that reads a property file from java.util.Properties.load method and in doing so the placeholders are being ignored. Since this is an old app. and do not want to change at this point in time, anyone has any suggestions on how do I go about?
If you're using Maven, you can write a generic properties file as such:
prop.1=${val1}
prop.2=${val2}
...
Then using the Filtering feature of the Maven Resources Plugin, you can do the replace your placeholders depdending on your maven profile.
I want to add different languages support in my Spring Web-MVC application without adding message_language.properties file for each language.
But I found message_language.properties file solution everywhere.
I searched deeply but I haven't got any solution for it.
please suggest me any solution....
Its not clear what are the reasons why you search for a different solution. Perhaps not what you want, but many projects that require dynamic language addition use database backed resource bundles (technically speaking its the solution without the properties file, but essentially the approach is the same).
If this is what you want you can check out the blog http://www.webreference.com/programming/Globalize-Web-Applications15_Java_ResourceBundles/index.html.
The following stackoverflow could be helpful as well
Database backed i18n for java web-app
I write applications that need alot of options. These options can be handed to the application by a xml file. Theses files are quite big with some levels and a few dependancies not modelable in a schema.
So the file passes the jdom schema check. Now I want to create some config object for the application and set some variables in some classes.
I don't really see any way not hardcoding the names of the elements and attributes and then looping over these elements and creating new objects.
This makes a 20kLoc application have 25 classes only holding configurations for other classes.
Is there some golden hammer rule how to use xml and customize applications. It comes down to putting the information in the file into some lists, hashtables and attributes of objects.
Can that be done easier? Some awesome framework, maybe? Reflection? Beans? Beans is just a hype word for java programming, or am I missing something?
Who controls the schema of the configuration files? If you can change it, you can simplify it enough to limit the number of classes needed.
If they are imposed from the outside, you might get some traction with Apache Commons BeanUtils and Betwixt.
My WicketApplication.properties file has grown very large, and now to keep it more readable I want to categorize properties in different files. Is there a way to accomplish that and still access the properties like if they were all in the WicketApplication.properties?
See org.apache.wicket.settings.IResourceSettings.addStringResourceLoader(IStringResourceLoader).
You can implement your own IStringResourceLoader which may load from wherever your want.
You can use property files dedicated per page or even component:
AddressPicker.properties - properties specific to an AddressPicker.java componen
ProfilePage.properties - properties used only on a given page (ProfilePage.java)
WicketApplication.properties - for aplication-wide properties (WicketApplication.java)
Wicket, when looking for properties for a given component, will look for the property files in the same order as above. AFAIR Struts2 uses exactly the same technic.
Please look at Wicket documentation: https://cwiki.apache.org/WICKET/i18n-and-resource-bundles.html.
As a last resort, you could write multiple files, but merge them into a single WicketApplication.properties as part of your build process. Unix has a tool precisely for doing this.