No tutorial presents a concrete example of how an internationalization plug-in fragment is created an used. I need translations to the plugin.xml's and source code files. Trying to wrap my head around where the translations go, and where the i18n facade goes.
1. How does that fragment apply to an multi-plugin enterprise application, and more importantly, how do all those plugins externalize their strings inside appropriate folders in the fragment?
2. What about external JARs? How does the mechanism provide translation support for external resources?
3. With the risk of being a long-shot, would it be possible to provide independent translation of a view or perspective? Not necessarily at runtime, because I know bundles can't be dynamically switched.
There is some help available, this article lists the process. It's based on Eclipse 2.0 (!) but the basic ideas are still correct.
An even better article is this tutorial by Vogella
For each plugin you need to translate, you will create one plugin fragment. The fragment is associated to one host plugin, so you need several fragments. Each fragment can contain several languages though. The languages are separated by the folder structure as described in Step 5 in the first article
I am guessing you are referring to non-eclipse Java jars that you have made yourself, yes? If so, that is a completly different process, best suited for a separate question with the Java tag. Oracle has a guide that may help. But keep in mind that you only need to translate the content that the user is exposed to. So a refactor to keep all user visible strings to the Eclipse plugins might be a good idea.
Are you referring to the name of the view/perspective? If so, yes. You can translate the information you give in your plugin.xml aswell. See Vogellas article, chapter 3
Edit:
At nr.3 I was referring to choosing which View to translate (e.g. via a view menu), then restart the app, then only the said view should translate
Well.. I think of a way that would work in theory, but I'm not sure its the best alternative.
So translatation is based on locale. And given the locale a certain translation is chosen. If no appropriate translation exists, a default will be selected.
So if your View menu were to change the locale of the application to, say "us-en-v1", and you only had one view which had a translation for the locale "us-en-v1", that would mean that particular view would be translated, but the rest of the application would use a default (could be that they default back to the closest translation, dont remember exactly).
Then for each view you would create a new translation and use a unique locale for each.
That should work, but it abuses the way translations are supposed to work, so it could lead to issues.
I've done something similar at one time, one app was used in the same language but different customers had different vocabulary. So we used the i18n to make the application use the right terms by defining our own locales.
We are using http://babel.eclipse.org/babel/ to let people translate existing ressources. The build process adds the required language fragments to the artefact. Each plug-in defines its own Messages.properties / Messages.java file.
I guess, you can't do much about external jars.
For instance:
public final class MyMessages {
// a string member as you reference it later in the code
public static String login_window_user_label;
// static initializer which initalizes the fields in this class
static {
NLS.initializeMessages("mymessages", MyMessages.class);
}
}
And (usually in the same package) you have a properties file, in this case,
mymessages.properties
which includes the string:
login_window_user_label = Enter username to login to {0}
And within the code you do:
String userNameLabel = NLS.bind(MyMessages.login_window_user_label, Environment.getName());
Thats how we make our bundles "translatable". The build generates the language fragments and the babel server instance allows the translation.
Related
I have a problem with translating default context menu items on TextField. There's no documentation about this menu in JavaFX javadocs (at least I couldn't find the one).
I can manually create new context menu on each TextField, rewrite the exising code and just change displayed text, but is there a sense in that? I can't believe that no one thought about this when designing JavaFX components.
So, my question is - is there a way to overwrite these values?
The text displayed in the context menu is stored in properties files that are read into a resource bundle. There is a collection of properties files with somewhat limited support for different languages. You can see these files in the source code repository.
It seems to be quite hard to add support for unsupported languages on the fly: there is a related question here - though I am still hoping someone who understands better than I how to do this may add a better answer to that.
In the meantime you might want to file a request at JIRA for support for additional languages - better still provide a properties file for your language of interest by translating the values in those linked above and submit it.
Hello there fellow Android developers. I am looking for some feedback. I am about to do a major international deployment of an android application. Something I need to worry about is language settings. What I have done right now is used the default language setting specific /res/values- setting where you have multiple folders called values-en, values-es, values-pt, things like that. So what I am wondering the following.
When my android default strings.xml is in English, will the way I am handling language be sufficient. It works here in development and probably deployed from the US store. But when deployed from other stores will the device think, I am from the Spanish store so the default strings.xml file should be in Spanish, or will it know, I am Spanish store so I will use values-es?
Anyways I would like feedback from someone who has deployed like this before please. It seems to be a question that is pretty guessable, however I am wanting to confirm with other developers what their experiences have been.
Thanks,
Anthony
If your read this page, it stated :
To add support for more languages, create additional values
directories inside res/ that include a hyphen and the ISO country code
at the end of the directory name. For example, values-es/ is the
directory containing simple resourcess for the Locales with the
language code "es". Android loads the appropriate resources according
to the locale settings of the device at run time.
Add the string values for each locale into the appropriate file.
At runtime, the Android system uses the appropriate set of string
resources based on the locale currently set for the user's device.
The language folder that is used is based on the user's selected language, not anything relating to where they are. You can test what each language looks like in your app by changing your device to a different language.
From my experience, the selected language resource is based on the selected language on device, so no matter which store your app is downloaded from, if the device language setting is english, values-en will be selected.
But you don't need to worry about it, as long as you have i18n files for all language you want your application to be translated to, the device will do the rest of the work for you.
What is the difference between Java working set and Resource working set in Eclipse?
The Resource working set is more general and it can include not only the Java applications / projects, but let me put it this way:
Let's assume a daily life of a Java developer. Do you suggest him/her to use Resource working set over Java working set? Is there any specific situation in which you prefer one over the other?
It sounds like this should have answered the question:
http://www.avajava.com/tutorials/lessons/what-is-a-working-set-and-how-do-i-use-it.html
A Working Set is a subset of your Eclipse projects. You can create
different Working Sets and then select which Working Set to display in
the Navigator view.
Specifically:
"Working set" (in this particular context), is an "Eclipse thing"
The purpose of Eclipse working sets is to help organize your projects
A project consists of "stuff": source code, bitmap graphics files, WSDL's, CSS style sheets - just about anything imagineable.
Consequently, Eclipse projects are organized (glancing at my J2EE perspective, for example) into subsections like "src", "WebContent", "Services" and so on. A project itself can be one of many different types: a "Java project", a "Java Swing Design project", and "Dynamic Web Project" and so on.
Similarly, an Eclipse Working set can be one of several different types: a "Java working set", a "Breakpoint working set ... and a "Resource working set".
As with Eclipse "Views" and Perspectives", you can usually access any project resource you need any time you need it. Selecting one or another perspective simply makes the object (e.g. "Problems pane" or "Build list") easier to get to.
Which kind of "Working Set" you choose - or whether or not you use working sets at all - is largely just a matter of personal preference and convenience.
Please let us know if you still have any further questions.
PS:
Additional links:
https://www.ibm.com/developerworks/library/os-eclipse-visualstudio/
As mentioned, many developers load all their projects into a single
Eclipse workspace. It's convenient, but it can sometimes create too
much clutter. In addition to closing unnecessary projects, you can
define working sets: groups of elements (projects, folders, classes,
etc.). Eclipse can use working sets in different views (such as
Package Explorer) and operations (like searching).
...and:
help.eclipse.org: Working Sets
A working set in the context of eclipse is a logical grouping of related projects to ease search and organize views within the IDE.
A resource working set can capture all types of resources - maybe java source, html, xml, javascript, images - anything that exists within the scope of the projects included into the working set.
The Java working set is a different working set (it is NOT a subset of a resource working set!) which captures only those java files which belong to a source folder and are being compiled into the classpath, or those java files which belong to a module (library) in the build path. Hence, it lets you lookup java "classes" which are in the classpath. Note that all java file in your project may not necessarily be built into the classpath (for example when you exclude a java source file, it does not get built any more). But a java source file which is not included in your classpath can still be detected by a resource working set (you will notice that the icon for an included java source file is a solid J, while for an excluded java source, it is a hollow J).
Example:
Say you have two projects p1 and p2 of which p1 belongs to the working set but p2 does not. So:
MyClass.java (belongs to p1 and included in build path) - Shows up in java type search (Ctrl + T) and also in resource search (Ctrl + R).
MyOtherClass.java (belongs to p2 and included in build path) - Does not show up in java type search nor in resource search.
MyExcludedClass.java (belongs to p1 and excluded from build path) - Does not show up in java type search but shows up in resource search.
MyExcludedClass.class (belongs to a dependency jar in the build path of p1) - Shows up in java type search but does not show up in resource search.
MyWebPage.html (belongs to p1) - Does not show up in java working set but in resource working set.
MyOtherWebPage.html (belongs to p2) - Does not show up in java type search nor in resource search.
MyConfig.xml (belongs to p1) - Does not show up in java type search but shows up in resource search.
So, in the context of a Java developer's use: I use Java working sets to look up types / classes defined in Java, whereas the resources working set to lookup all different types.
One difference between the working sets is that they provide different editing wizards (as stated here: http://help.eclipse.org/helios/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Fconcepts%2Fcworkset.htm). If you edit a resource working set and a java working set respectively you will see they use different screens for selecting which resources/projects are included.
Apart from this I haven't found any other difference. It also does not seem to differ which resources you can choose in any way. So to answer your question which one would be recommended I would answer "it doesn't matter" since they behave the same way.
A working set is a subset of your workspace and is a way to organise all your projects. With the different types of working sets you have also different types of editing wizards as described here.
Editing wizards
For java projects the Java working set is a more comfortable way to work. Let's assume you have a bunch of java projects in a java working set and you have just opend the editing wizard of the Java Working set:
First of all you can see everything what is in the working set at the moment in the right table. If you now want to include another project you can simply select the project(s) and press CTRL+a. To remove a project you can press CTRL+r
In the Properties of a Resources Working set you don't know what is in the working set until you have scrolled to the bottom of the tree view. This is impossible for people who have 300+ projects in their workspace.
Structure
A benefit from having two types of working sets is structure. There are situations in a daily workflow where it is useful to have different types of working sets, because they have different icons. If you have resources like config files you can create a Resource working set namend 'config files' and put all the files in there.
Afterwards you can open your File Search and search in your config files. This is possible because you can define a working set as a scope for a search.
There are several parts in Eclipse where you can select your working set with the Select working set dialog.
I'll try answering from the perspective as a plugin developer. From the API:
A working set is intended to group elements for presentation to the user or for operations on a set of elements.
This can be any kind of element and does not have to be a project. Working sets are provided by plugins, which can decide what kind of elements can be added and which provide wizards for adding elements as well as operations that can be performed.
It doesn't really matter for a project in which working set(s) it is in. A Java project is still a Java project if it in a resource working set. It only affects some views, dialogs and operations that filter for certain types of working sets.
Besides Java and Resource working sets, there are also Breakpoint, Task, Plugin and C/C++ working sets (depending on your Eclipse setup of course). Some views only show certain types of working sets while other views don't seem to filter them. For example the "Open Type" and "Open Resource" dialogs seem to display all types of working sets. The "Open task" dialog only shows task working sets.
So what is the actual difference between Java and Resource working sets? I haven't seen any functional differences yet. All standard views and dialogs either seem to handle both or none of these two working set types. Most plugins don't seem to care about the distinction at all - but that doesn't mean some plugin could handle both types differently.
On the other hand resource working sets seem to be a catch-all for any type of project, so it makes sense that most plugins don't make a distinction here.
For example if I were to create a plugin that provides an option to analyze Java projects, I would add that operation to the context menu of Java working sets but certainly not to C/C++ working sets. But some people might use resource working sets because they have both Java and C projects in the same working set. So I have to add the Java-specific operation to the context menu of resource working sets too.
I have a web page with lots of text.Is there any means through which I can translate it,without using resource bundle(which involves using properties files,requiring key value pairs for all words.)?
Thanks for your precious time.
An alternative is to create separate views for each language. So a "mypage_en_US.html" for the US-english version and a "mypage_en_GB.html" for the british-english version. This gives you total control over the text and layout but has the drawback of possible code duplication if there is any logic in your view.
Wicket uses pretty clean views which should hardly contain any logic so this works pretty well there.
Just be innovative here. If you are getting shitty copy pase work. Write a program to convert the properties file and then use that properties file using google translate api, but yeah end of the day you will have to go with properties file.
I belive there would be other way too using google translate api again, would love to hear that myself too
Depends on your web framework.
For example, Wicket can apply I18N on webpages in two ways :
- using I18N files and resourcesbundles, with placeholders where required in the page
- by having totally separate pages, one for each language. The page template itself is postfixed with the locale, much like property files : HomePage_en.html, HomePage_fr.html, etc.
Other web frameworks may have similar features. If you're using raw JSP/Servlets, I'm afraid you're pretty much on your own.
But it's totally possible to implement your own templating system. For example, you could use a set of Freemarker templates, and load the one that matches the desired locale.
I am a new developer in Android. Currently I have started working on an app. I dont have any colleagues in Android so for my doubts and queries I am depended only on Stack overflow.
In my app I have placed three Edit boxes as follows with an ok button at last
FirstName:_____________
LastName:______________
DOB:___________________
When the user enters all data above and clicks the OK button at last, I am going to do the following process
Store the datas in a database
Send it to a particular URL
the data send to the URL will be get saved there
i just want to know how to implement this. What concept to be used.....
The actions, views and activies in Android are the baked in way of working with the Android UI and are an implementation of a model-view-viewmodel pattern, which is structurally similar (in the same family as) model view controller.
To the best of my knoweledge, there is no way to break out of this model. It can probably be done, but you would likely lose all the benefit that the existing model has, and have to rewrite your own UI layer to make it work.
You can find MVC in the followings:
You define your user interface in various XML files by resolution/hardware etc.
You define your resources in various XML files by locale etc.
You store data in SQLite or your custom data in /assets/ folder, read more about resources and assets
You extend clases like ListActivity, TabActivity and make use of the XML file by inflaters
You can create as many classes as you wish for your model, and have your own packages, that will act as a structure
A lot of Utils have been already written for you. DatabaseUtils, Html,
There is no single MVC Pattern you could obey to. MVC just states more or less that you don't should mingle data and view, so that e.g. views are responsible for holding data or classes which are processing data are directly affecting the view.
But nevertheless, the way Android deals with classes and resources, you're sometimes even forced to follow the MVC pattern. More complicated in my oppinion are the activites which are responsible sometimes for the view but nevertheless act as an controller in the same time.
If you define your views and layouts in the xml files, load your resources from the res folder, and if you avoid more or less to mingle this things in your code, then your anyway following a MVC pattern.
Google has tutorials for doing simple forms and taking actions when buttons are pressed. You should start there.
Next try the URL thing and next try the save data thing. If you follow the form tutorial you'll know where put code to execute when button is pressed (read the data tutorial).
If you follow others tutorials (to navigate) you'll know how to redirect to a URL (I would read "intents" but I'm not pretty sure, I'm not very prepared on Android). I guess that you should only "redirect to http://" and the system will decide (or ask the user) to open it in a browser or something diferent (like the youtube app). If you want to control the window navigation read this (but I don't recommend it).
But the bottom line is: read the tutorials and try things until you feel that you grasp the philosophy of the technology. Then search for specific things link redirecting, saving data, or taking a special action.