This content has been marked as final. Show 18 replies
Looks very bad....
we'll have that probklem in near future too....so is there any way to help?
If you are importing in the same Application ID , there is no problem.
All you have to do is keep the xliff file and re publish your translated version with it.
If you are importing in another Application ID, You have to redo the translation completely.
Nice and clear!
I understand the issue. We will at least take a look at this for Application Express 3.0.
Now i do not understand your post....
If you export workspace ID and import on another db then workspace id is the same...
If you import with same APP_ID in same WORKSPACE ID then all should work...so where is the issue?
Could you please elaborate the problem more widely...
We will face into this situation in near future and I cannot see the incomming problem?!
Francis defined the problem clearly: "If we import an application that has a translation ... into another APP_ID , we lose the translation."
Same or different workspace IDs make no difference. If you change the application ID on import/install, you lose the translation.
We blogged on this problem on the following link http://iadvise.blogspot.com/2006/12/apex-deploy-your-multilingual.html
We are now working on an Apex application that will help in step 3 of the translation process. It is possible to upload an xliff-file, to make a translation for every source element and to create the xliff file again with the translations. The idea is also to make a kind of dictionary so it will be possible to automate a part of the translation process for words that are repeatedly used. Keep an eye on our blog where we will explain some more on this application.
Btw, which tool do you use to make the translations ?
This is a good idea.
We also tought the same sort of program that would be a add-on to apex to translate words from a global dictionnary using the xliff file. But we never got to developing it.
We currently manually translate our applications.
The other big problem with the translation, is that in the xliff file you do not know what object you are translating. It would be nice to at least see if it is a region title, a button or something else.
You can derive the 'type-of-unit' that you are translating.
On the one hand you have to extract the first part of the ID attribute in the <trans-unit> tag you can find in the xliff-file
On the other hand there exists a table holding those types: flows_020200.wwv_flow_translatable_cols$;
There is not a one-to-one match, but it is possible to do the mapping. I' am preparing a blog on that. So keep an eye on http://iadvise.blogspot.com/
The second element in de ID-attribute of the <trans-unit> tag corresponds with the id-column in wwv_flow_translatable_cols$. See http://iadvise.blogspot.com/2007/01/apex-xliff-translation-step-3.html
There we explained how you can transform the xml-file to a relational table.
We have put on line our extension to APEX for translating an XLIFF file.
You can find the utility on following URL: http://www.iadvise.be/XTra4o
This is an Apex application; the main advantage vis-à-vis a 'traditional' xliff-editor is that we show for every translatable item the object in apex it corresponds with !
You can read about it on our blog: http://iadvise.blogspot.com/2007/02/apex-xliff-translator-editor-step-3.html
we hit all the time error:
ORA-01706: user function result value was too large
Unable to upload & seed file.
Return to application.
Our upload file is cca. 530 KB. Any help?
That's a bad error. We should correct that into something a little more informative. I'll file a bug on that.
What's happening is that no translated element can exceed 32K. So you must have some translation units which are exceeding 32K.
I don't believe the right answer is to truncate it. The right answer is to raise an error with a more informative message than ORA-01706.
I hope this helps.