Is there a best way to localize the language settings? Say the situation is that you have already a working application in, say, French, and wanted to completely localize it in English.
So is there any way to easily localize the application while minimizing the impact on the application's code, I mean there mustn't be any major changes to the code itself but adding some would suffice. I've heard of using resource files in VB6 but it seems to have an issue with its fonts specially in Japanese characters, it throws out a garbage chars specially on labels. Now, what's the best way to change the charset of a application without applying too much changes in the applications code.
This application has a legacy code to I have to deal with it.
I use resource files, and replaced (almost) every string in the codebase and UI with an ID.
Whenever I display a string, I then call a single function that takes a string like {#1234} and loads string ID 1234 (using LoadString() and returns it.
For the UI, I enumerate every control on the form and pass the visible strings to the same function.
This meant a single call to Localise Me in the Load event of each form and a TranslateString("{#1234}", "name", Name) whenever I set/display something dynamically.
For the fonts, see this example from the Visual Basic Programmer's Guide. I call this on every control as part of the Localise method.
Don't forget that different fonts and languages take differing amounts of vertical space for the same text. The form layout also needs to be adjusted to take this into account, or reflow dynamically (align controls to longest label, shift down to allow for longer full width text, etc.)
Regarding the "while minimizing the impact on the application's code" part of the question, I would suggest encapsulating the resource-lookup-related features into a class of its own, exposing methods to fetch a string (by passing a culture specifier argument).
Then the bulk of the work is to convert your code from perhaps hard-coded strings to method calls to retrieve the appropriate strings. Implementing a variant of this answer: Implementing String.Format() in VB6, could greatly simplify your life if you also encapsulate the notion of 'culture' and introduce some cultureInfo argument to this StringFormat method's signature (perhaps call it StringFormatLocal).
The point being, if the current app isn't localized, it's probably not concerned about localization; localizing it means introducing a new concern so in order to affect legacy code as little as possible, you'll need to seek & destroy "magic strings" and "magic formats" all over the code base (and if your UI has hard-coded design-time captions and images, remove those as well), replacing them with calls to your localization API - keeping the localization concern separated.
I'd like to see another answer here with more details about storing, loading and especially using non-ANSI string resources...
Related
I have an iPhone app with interface languages in Toki Pona and Dothraki, which do not have ISO 639-3 codes. According to the ISO 639-3 standard, you can use the range qaa-qtz to represent languages for local use, which I have done (Toki Pona = qtp, Dothraki = qdt), but still get the warning from XCode "Unrecognized Locale".
It seems like I might be able to extend the main bundle class, but looking over the documentation, nothing seems to relate to adding non-ISO languages. I'm also aware of the text "If necessary, you can use a language or locale code that is not known to the NSBundle class or Core Foundation bundle functions. For example, you could create your own language designators for a language that is not yet listed in the ISO conventions or available as a language in Xcode." at the end of https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/LanguageandLocaleIDs/LanguageandLocaleIDs.html
In any case, I mostly want to get rid of this warning. Any help would be greatly appreciated!
https://forums.swift.org/t/proposal-ns-locale-identifiers-etc-should-have-custom-types/9367/8
have a look at the above link.
Check if the languages are added as Localizations
I believe I have a solution however slightly complicated one. You would need to create a setting option within the app to use those made up languages and to load them manually from a file when a user sets them. For example, let's say your app consists of one label and the user sets the option to the made-up language you would call a method to set the language and the text on that label would update accordingly. I don't know whether this makes sense to you?? Basically, if the user uses the made-up languages that would override any system localization they have. It is doable it would just take time to implement it.
I am attempting to build a simple application using wicket and have been impressed so far. I have been taking advantage of the Component class to determine behavior of elements on the page based on user input or the model. I see the component model similarities with JSF, but find the wicket lifecycle easier to manage.
What i haven't been able to understand is having to add every component to the tree for every wicket:id mentioned on a page, especially for ones without any children. it seems heavy handed to have to build up the tree in java code when the tree has already been somewhat defined within the markup. what am i missing?
edit
I should probably give an example. I have a label for an input box that in some cases i want to be able to modify. 95% of the time the text and attributes i have for the label in markup will be fine.
Short answer: Yes, you have to add them.
Long answer: You can create custom code to do this, but I doubt it's worth the effort.
With JSF, you use a non-html tag, which has one component type associated to it - for example, h:inputText correspond to the class HtmlInputText -, so it knows what class to instantiate.
With Wicket, the HTML file contains only (with a few exceptions) HTML tags, and you have to instantiate a concrete component for each wicket:id-marked tag you add to the markup, because it can't know for sure if <span wicket:id='xyz'> means a Label, a FeedbackPanel, a WebMarkupContainer, or some custom component.
With JSF you do in the markup what, with Wicket, you do in Java code, that is, to build the component tree, bind components to properties, and handle events. It keeps everything in one file (you don't have to create a class for every template file), which has many, many cons (some may think it has some pros, I digress).
You page is never just a simple form that does nothing. You want to convert and validate the input, you want to process the submit, you want to update components using Ajax. With JSF, you do all that in the (non-compilable, type-unsafe, poorly tooled, non-refactorable) template, making it bloated with expressions, configuration tags, and - gawd forbid - business logic.
If Wicket had support for this (and, for the matter, it has the flexibility needed for you to build this add-on yourself), you would have to add lots of extra annotations (special, non-standard tags and attributes) to the markup, to declare what class to instantiate, what model to update, what validations to execute, etc., compromising two of the beauties of the framework, the clean HTML template, and the clear separation between visuals and logic.
One framework that tries to do more in the template, while remaining less bloated than JSF (which isn't that hard anyway) is Apache Tapestry. But as can be seen in its tutorial, you still end up having to use non-standard tags and following arbitrary conventions to bind the template to the code (you may like it, but if this is the case you have baaad taste, sorry :P).
I have a label for an input box that in some cases i want to be able to modify. 95% of the time the text and attributes i have for the label in markup will be fine.
You could try to wrap the content of the label in a Model, enclose that label in a container and repaint the container (target.add(container);).
Offcurse you should add them.One of the most powerful facilities of wicket is that allow you to make a reusable components espacially html components.
There are a million ways to build a house, but most people wouldn’t
consider building toilets, bathtubs, and glass windows from scratch.
Why build a toilet yourself when you can buy one for less money than
it would cost you to construct it, and when it’s unlikely you’ll
produce a better one than you can get in a shop? In the same fashion,
most software engineers try to reuse software modules. “Make or buy”
decisions encompass more than whether a module is available;
generally, reusing software modules is cheaper and leads to more
robust systems. Reusing software also means you don’t have to code the
same functionality over and over again.(wicket in action:manning)
So to have a reusable wicket pages, wicket just needs a html page to show it's components hierarchy or their positions. The types and model of these components left to programmer.
I have a set of GWT UIs, some created directly in Java and others created using UI Binder ui.xml files.
I localized them following the official GWT guidelines (e.g. creating interface extending Messages interface).
I now wonder if there is an easy way to write a unit test to validate that message keys get replaced by the corresponding values from property files?
I guess I could do that using GWTTestCase, but actually I don't need a browser to render the page. Instead, it would be enough to get the raw string output and check with some regex that the messages are present.
Is that possible? Or is it better to test such things in running application like using Selenium?
Just a note. Besides the important things you are trying to validate, one of the critical points in my project during messages localization tests is to see: if the translated text fits the allocated space. If it's a box of fixed size, overlapping texts don't look nice. And this cannot be checked with unit tests. That's why the manual review is in to-do list when new locale is added or certain labels/messages are changed.
I'd recommend Selenium. Checking that the messages are present could be tricky, because in that case you should know the place where the label is located, in which tags. In my opinion, using GWTTestCase makes sense when it comes to testing controllers' behavior. Simple search by value guarantees only presence but not correct placement.
I think, it also makes sense to use those translation properties in the tests, so the strings are not duplicates in the tests.
I am making a custom textbox control and am thinking about adding keybindings in the constructor that execute commands to open and save files. I am also thinking about handling the find and replace dialog from within my textbox control.
Is there a reason I shouldn't do this?
--Edit--
I am planning on only using this control in my current application. One of the reasons I am thinking of doing this is to avoid binding to the textbox's Text property, since this binding seems like it would be just as inefficient as updating a string on the textbox's textchanged event.
Well, flexibility comes to mind. Consider the following scenarios, which would be impossible (or at least difficult) in your control:
You want to handle multiple or different methods of opening a file, but it depends on your application.
You want to use your textbox but limit the functionality -- e.g., Find/Replace is not allowed.
You want to change the behavior of any of that in one application but not the other. For example, in app A you want to tack on an extra slash to the end of the text, but in app B you want to add a custom folder name.
In general, I would consider something more generic. Something like a textbox has a specific purpose; enhancing that purpose is fine, but you're going beyond that. You're taking logic that rightly belongs to the app and putting it on a specific control. That limits what you can do with the control across multiple apps.
Of course, if you're writing a control specifically for one and only one app, you don't need to worry about these things. But I would still consider it a bad practice, myself.
I am looking for a nice framework for developing a GUI builder Application. We have an application where 100Os of custom data entry forms and their print formats are required and each client will need some modifications on these. We have a developed a product using java based open source templatnig frameworks so that the layout and field definition are stored in database and rendered dynamically to the user. We also have an appication to design these forms but cannot do visual design.
Now I am trying to make a Visual Form Designer application for generating these forms. Can any one suggest some open source frameworks than can be used? Can I use Eclipse Visual Editor? Or is it better to develop some kind of parser for HTML using AntLR and then parse the HTML output from already existing GUI builders like Dreamweaver to get the desired output?
Thanks and Regards,
-- Kannan
Oooh, great question!
I wouldn't know any readily availble framework that you can use. Depending on your needs however, I think rolling your own shouldn't be too hard.
First of all, you probably wouldn't want to give the users too much freedom. Freedom only gives them the opportunity to mess things up and make the resultant forms hard to use. I think from your description that the fields are pre-defined, so that the user only needs to customize which fields appear on a given form, and in what order. Order can be a simple thing like top-to-bottom. Some semi-intelligent automatic layouting could be used to conserve screen space. Adding a feature to group fields together would probably also be useful, and grouping would lead to some kind of standard "group" widget.
Accepting simplified functionality like this, you don't really need the flexibility of a full gui editor. A couple of listviews, maybe a property sheet and a preview window will be enough to give your users the functionality they need.
Of course, this only holds for screen forms. Print forms may be trickier to layout, as people may want to cram as many fields as possible into very little space so the entire form can fit on a single page or something. I really don't have any suggestions for you there, but maybe a similar "simplified" approach with some intelligent auto-layouting could work.
Overall, my advice would be: Keep It Simple! (S... ;)