These two videos below show how you can work with reports in multiple languages in an applicaiton.
The official Alpha Software blog, covering our view of mobile application development, rapid application development, codeless AJAX, high performance web databases, desktop databases, SQL database reporting, SQL database development, SQL database programming, AJAX GUIs and AJAX front-ends, and more.
Back in March, I gave you a sneak peek at Alpha Five's new internationalization support. We extended language definition strings from the grid component to the Tabbed UI component and the page layout builder. Then shortly after, we added 130 currency symbols.
When you're in the cloud, you want everyone to be able to understand your app. That's why we continue to extend our internationalization support.
I told you about these new abilities, but I haven't shown you how they work in a real, live Web application. So let me introduce you to what Alpha Five expert Jim Dusoe built.
Jim developed an application for Woolworks Live, a company that provides image resources to the fashion industry. The website had to operate in English and Japanese. Using Alpha Five's language capabilities, Jim developed the site to seamlessly translate English into Japanese and vice versa for the end user.
Jim shows you how he built the Japanese side of the app, how he's able to make it flip from one language to another, what it looks like from the end user side, and much more. Hit play on the video above and start watching. And if you've already worked multiple languages into your Alpha Five Web apps, send me an e-mail with a demo. We might even feature it on the blog!
If your user is working in the Grid component against a SQL database, it will send back an error message if your user duplicates a record or makes some other mistake. You, as the developer, understand what the error message means, but your user might not. Simple, concise error messages will provide a better experience for your app.
Here's how you do that. Use the new OnSQLExecuteError in Alpha Five Version 10.5 to customize error messages that are returned by the database server. This allows you to intercept them and change them before they are presented to the user. You can also use language tags to internationalize your error messages. Now your users, no matter what language they speak, can clearly understand what went wrong.
Watch Selwyn demonstrate how simple it is in under three minutes. Then start customizing your messages.
Hola! Bonjour! Jambo! Buongiorno! There are so many different ways to say hello. And when you're building a database application, there a lot of languages you might need to create it in.
Arguably, internationalization wasn't as much of an imperative 10 or 20 years ago as it is today. In the client server era, you weren't necessarily having people around the globe connecting to your internal corporate applications. In the global Internet era, by definition, your application might need to be available to people all around the world. And it should respect them by speaking their language.
This is one of the reasons we made sure to include support for internationalization in Alpha Five Version 10. Language definitions were first introduced in the grid component, but they now have been extended to the Tabbed UI component and the page layout builder. Watch the video to learn how to use language definition strings in each.
|NEW V10 FEATURE: Language definition strings extended|
In a recent InfoWorld article, Peter Wayner talked about how to choose the right programming language. As you can see in the comments, the article elicited some rather visceral reactions from a number of developers.
This is an example of how people tend to get a little uppity when a publication or pundit tells them which language they should choose. I commented too, because despite what you might hear, there's only one way to choose a programming language: Select the tool that meets the needs of your application.
Here's the comment I posted:
There's only one way to choose a programming language: understand the application requirement, and choose a language and/or dev platform that best meets it. No one language is right for every task. If I am coding an embedded app, I'd personally opt for C or Java. If I'm coding a Web database app, I'd opt for Alpha Five. If I'm coding a Windows system tool, I'd probably opt for a .Net language or C++. The #1 rule of app dev: CHOOSE THE RIGHT TOOL FOR THE JOB.
Take a look at the article for the full story.
Coach Wei over on Con's Apache blog poses the questions, "Why do 'cool kids' choose Ruby or to build Web sites instead of Java?" and, "Why isn't built in Java?"
I can't answer for cool, since I was cool a few generations ago, and am now, er, old. But smart developers pick the appropriate tool for the task, and don't try to do everything in (or limit themselves to) only one language or platform.
Architecture isn't about, nor does it define, the implementation language. You don’t choose a language first. An architecture defines the structure, relationships, and patterns that exist between the pieces or components. Then you pick the language.
Another question Coach asks is, “Is it the lack of frameworks? I bet there are more Java frameworks than the population in China.”
How true -- and building Java applications means using a healthy (or unhealthy) set of them. The amount of sheer “stuff” you need to know to be effective in Java is simply daunting.
PHP, Ruby (on Rails) and Python are all small and easily learned. People have built frameworks for them, but you often don’t need them, and can keep the code nice and simple.
PHP v. Ruby v. Java? A red herring that reminds me of the C vs. BASIC and the Java vs. Visual Basic wars. Arguments not worth having.