So all you need to change in your translation workflow is the creation of the XLIFF File, the rest stays the same as you are used to right now. The best thing is: after you translated all those texts you can take this XLIFF File and re-import it into APEX using the standard APEX Translation Upload XLIFF Functionality. The next time someone wants you to change a Button Label on you can say: “Sure, no problem.” Now you actually know where the text you are working on is used and what it’s purpose is. Once you load that into your XLIFF Editor it looks like this: It creates an XLIFF File in Format 1.2 which contains tons of extra information, like: the Application Structure and the Context (what, where) a Text is used. The ApexLib XLIFF Export Tool is thought to be used instead of the builtin APEX XLIFF Export. Here comes another ApexLib Tool to the Rescue: The ApexLib XLIFF Export Tool No wonder this is a complicated task, when you take a look into the XLIFF File generated by APEX you see something like this: īut don’t you panic now. That’s the point where you either stutter “.i.i can’t, i don’t know which of all these Logout-Texts is the button on …” or you try to change one after the other until you find the right one. Now imagine your customer wants you to change the text of a Button on from “Logout” to “Goodbye”, without changing the other Links and Texts on this Page. So all you can do is a word by word translation, which sometimes can create rather funny results (ever tried to translated something with Google Translation where you know what the outcome should look like?). You just see a text string without knowing where it is used. Picture of an XLIFF Editor (CMS Kite) with a standard APEX XLIFFĬould you work like that and create a correct translation? I doubt it.Īll the information about what you are translating is missing. At the other end there are Translation Suites with Term Databases and Auto Translation Support and whatnot.īut basically the all work similiar: at first they read the supported XLIFF File, the betters now do an auto translation and then the Files content is shown to the User. Of course there is a broad range of XLIFF Editors with different features, starting with a very basic Editor to simply translate string by string. They load this XLIFF File into an XLIFF Editor and translate all the texts in there. This File then goes to a Translation Office or to a colleague who speaks the required language. This File contains all text strings of your Application (that is all your UI Strings, not your Data) and from which to which language it should be translated. One of the Key Components of this Translation Mechanism is the creation of an XLIFF File. It gives you a set of tools to translate your Application and provide it in multiple languages at the same time. One of the many good things about Oracle APEX is the builtin capability to create multilingual Applications.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |