Google Translate integrated within xTra4o

xTra4o stands for “XLIFF Translator for Oracle”, and more specific for APEX.

xTra4o is an application that iAdvise has built, already a few years ago, that helps in the translation process of an APEX application. This tool is publicly available as referenced by the APEX OTN site.
Read our blogs  referring to this tool, posted in February 2007.

There is a one specific step within the process of tanslating an application that  APEX itself does not so well support; it is step 3 where you must translate all translatable elements within the so-called XLIFF file.

Our xTra4o allows to upload this XLIFF file and translate the individual elements via a specific editor.

A first surplus of this tool is the possibility  to write common terms in a Dictionary  and use this Dictionary for translating similar terms.

Today we have added an additional useful feature to the tool. For each source term you can get the translation via the Google Translate API. Following screenshot shows the new icon, you can click on to let Google make the translation. In the example English terms must be translated into French:

As a user, you can always adjust the proposed translation yourself and decide to add the word in the Dictionary.

We have discovered that Google does not always treat ‘special characters’ in a proper way. For some of those signs (like the ‘#’ sign), we block the API call. It is possible that we do not block all special characters yet, but this can easily be added. If you detect such cases, let us know via the feedback option in the tool.

To use this Google Translate API we started from the PL/SQL code that you can find on this blog.

Manually Editing Translations within Apex without Exporting and Importing XLIFF File

Everyone already knows that translating an application built with Apex involves the following steps:

  1. Map your primary language application to a translated application
  2. Seed and export the translation text of your application into an translation file (XLIFF file)
  3. Translate text identified in translation file
  4. Apply your translation file and publish

Joel Kallman referred to a less known feature in this context during his presentation last month – “Go Global with Oracle Application Express!”- at the ODTUG Conference in New Orleans. Since Apex version 2.2 it is possible to perform your translations even more rapidly, without the need to export and import the XLIFF file again.

Via Apex you can manually edit your translations within the repository. But, you still have to follow the same globalization process: mapping, seeding (without exporting the XLIFF file), translating and publishing (without applying the XLIFF file first).

So, to manually edit a translatable text, navigate to “Shared Components” > “Globalization” > “Translate Application” and follow these steps:

  1. Map your primary language application to a translated application.
    This 1st step is unchanged.
  2. Seed the translatable text (without exporting the XLIFF file).
    Click step 2. Choose your “Language Mapping” and press “Seed Translatable Text”. A message like “Translatable application 143 text seed complete for fr.” appears. Seeding is succeeded now. You may end this step because we don’t want to export an XLIFF file.
  3. Manually edit translation.
    From the “Translation Utilities” list (right on your page), choose “Manually Edit Translations”. The “Translatable Text” page appears. Within the search bar you can enter some search criteria.


    To edit translatable text, click the “Edit” icon; translate your text and press “Apply changes”.

  4. Publish the application (without applying the XLIFF file first).
    From the “Navigate” list (right on your page), choose “Publish Application”. Select the correct language mapping in “Create Application” and press “Publish Application”.

Finished!

This is an alternative and quick manner to achieve translations after small application changes due to bug fixing or other small modifications.

Last remark : Suppose you do have an application to translate using the XLIFF file, then you can edit your XLIFF file either by using a simple text-editor, MS-Word or an XML Editor (XML Spy or JDeveloper)… To avoid the repetitive work with these editors you can always use our own free utility, the XLIFF Translator. Within this translator we provide a kind of a dictionary, so it will be possible to automate a part of the translation process for words/sentences that are repeatedly used. For more information read the blogs about the XLIFF Translator from January 2007 and February 2007.

ApEx: ORA-20001: Sync Error

While trying to publish an translated application I keep running into the next error:

ORA-20001: Sync error: WWV_FLOW_PAGE_PLUGS.PLUG_QUERY_NO_DATA_FOUND …

After trying some more I got:

WWV_FLOW_PAGE_PLUGS.CSV_OUTPUT_LINK_TEXT
WWV_FLOW_PAGE_PLUGS.PLUG_FOOTER
WWV_FLOW_PAGE_PLUGS.PRN_PAGE_HEADER

After trying 25 times it was finally published but I was not planning to try that often each time. If you are running ApEx version 3.0.1.00.07 or 3.0.1.00.08 then this is actually a database bug but you can find a patch for a workaround on Metalink, Patch nr: 6456920.

Description ORA-22922 WHEN PUBLISHING A TRANSLATED APPLICATION
Product Oracle Application Express (formerly HTML DB)
Release 10.2.0.3

After running this patch I could publish my translated application without any problem.

ApEx Xliff ORA-31011: XML parsing failed

Recently I came across this error while trying to publish a translated application. The application needed to be translated in the polish language, this was the first time that I came across a language with special signs in it.

I quickly found out that I cannot just save the xliff file on my windows machine, I need to choose the correct type of file otherwise the special characters will be lost. So the translated language is polish and my target database has the WE8MSWIN1252 character set.

I saved the xliff file with type Unicode file using notepad. When I tried publishing the next error appeared:

ORA-31011: XML parsing failed. ORA-19202: Error occurred in XML processing ( LPX-00216: Invalid character 0 (0×0). Error at line 1 ).

Not really knowing what the problem could be I tried saving it as UTF8 type file with notepad. If I tried to publish the new file I got a different error:

ORA-31011: XML parsing failed. ORA-19202: Error occurred in XML processing( LPX-00210: ‘<' expected instead of '¿'. Error at line 1 ).

After some research I found out that notepad(Microsoft) adds a BOM (Byte Order Mark), these are 3 bytes at the start of the document that indicate the character encoding of the document. So I tried a non-Microsoft tool like ‘UltraEdit’ and saved my document with type UTF-8 – NO BOM. Now I could perfectly upload and publish my application.