- de - German
- es - Spanish
- fr - French
- it - Italian
- ja - Japanese
- ko - Korean
- pt-br - Brazilian Portuguese
- en-us - English United States
- zh-cn - Simplified Chinese
- zh-tw - Traditional Chinese
As you may already know, a developer-created Application Express application can be translated into any language. But for the development environment of Application Express (Application Builder, SQL Workshop, Access Migration, Utilities, Internal Administration), should this be translated into additional languages?
I am specifically interested in the market opportunity for Application Express, and not necessarily your personal preference.
If you wish to let your voice be heard, please feel free to take this one-question survey at:
http://apex.oracle.com/pls/otn/f?p=apex_lang_survey:1:0
6 comments:
Hello Joel,
i've been working a lot with the translation tools built in Apex and rather than having specific requests concerning the translation of Apex itself, i have got a "wish list" of new functionalities in this area ;-)
For instance, i'd like to have a grid edit page for the translations, instead of a report with edit links.
Another nice to have feature would be a translate all similar strings in one shot.
Also beneficial would be the possibility of switching automatically the translatable strings between the primary language and a translated language, an operation that i am doing now using a custom procedure that needs to run with additional privileges as the underlying table is owned by FLOWS_030000.
I'd also like to have a shorter route to publishing an application after making one or two changes in the translated strings, without having to seed, export, import, apply and publish.
Finally i think it is absolutely necessary that one can programmatically set the current language without incurring in one additional redirect. I have this requirement because i have collected some evidence about the fact that Google spiders don't like at all the double redirect that occurs when i change the language as result of an apex request (the only way i found so far to allow a user to successfully display an apex application in the desired language).
But in spite of this enhancements, i still find that Apex translation mechanism rocks and it makes really easy for anyone to build a globalized application.
Awaiting your comments...
Cheers,
Flavio
Hi Joel,
triggered by your posting, I have also written down some of my thoughts about APEX in more languages. See my posting More Translations for Oracle Application Express?
Patrick
further to my comment, i just noticed today that some content in the apex dictionary is not translated when is accessed from a translated version of the application.
For instance, if i run the italian version of an application whose primary language is english and i query dictionary view apex_application_pages, column help_text doesn't contain the italian translation, but still returns the english text.
Is this expect behavior or does make sense that it returns the translated text (as i was expecting...)?
Bye,
Flavio
Take a look at Moneythoughts. As someone interested in investing, you might enjoy what you read.
Hi Flavio,
Thank you for your comments. You should feel free to send comments/suggestions like these to me at any time (you don't need to wait for a blog posting).
These are excellent suggestions, and I've added them to our list of consideration for the next release of Application Express (it's obviously too late for APEX 3.1).
Can you please explain "the possibility of switching automatically the translatable strings between the primary language and a translated language"? I don't quite understand that.
As far as a shorter path to publishing, I agree - it would be nice to have a simple "synchronize". Just keep in mind - in your case, if you make one or two changes and there is zero UI or translation impact (and you already have a seeded and translated translation repository), you can simply publish - that's all. And even if you have added some UI but don't have corresponding translations, you can seed and publish - no need to export and import the XLIFF, as your net results with respect to translations will be zero.
Lastly, I agree with you about the additional redirect when changing the language programmatically. That's something I spent a lot of time on to figure out, but there was no easy solution. Regardless, we'll look at making this easier.
Thanks again for the great feedback.
Joel
Joel,
IMHO, you and your group can't and shouldn't do this by your own hands. First, you are not native speakers for 50+ languages, second, work is huge and your time is valuable.
Since APEX has avid and growing communities of users in many countries, who are native speakers of their own languages, why not letting them to participate?
You just need to publish a simplest kind of interface for translation like: "untranslated string" - "suggestion 1,2,3,..." - "votes for each suggestion". Anyone who needs a translation, can obtain link to these pages in their language, improve their translation in wiki way, get non-supported snapshot of current state of things and install it. Once translation is agreed to be "100% complete" by most users, it gets reviewed by expert and streamed into main release.
Thanks,
Maxim.
Post a Comment