This content has been marked as final. Show 18 replies
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?!
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/
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
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.