Community
Participate
Working Groups
The Babel PTT NL packs prevent the PDE editor from opening with an exception. They cause a SAXException. PW
I don't think this is a problem with the Babel PTT -- it is doing its job. See bug 270445. Reopen if I assessed this wrong, but I believe the PTT found (and pseudo-translated) strings that are not meant to be externalized or translated.
Created attachment 130644 [details] pseudo translation problems in PDE I've identified the problem. Some of the descriptions in PDE editor are in HTML snipets. See attachment for example. HTML parser throws an exception when we insert the "eclipse123456:" prefix to the string. Human translator knows not to translate the HTML tags. But, Babel's simple pseudo translation generator just inserts the prefix and breaks the HTML snipet. I cannot think of a simple solution. One workaround may work, but not fool proof. When we see string begining with the HTML tag pattern "<tag>", we insert "<div>eclipse123456:</div>" instead. This seems to solve the PDE editor problem. But, I've seen strings like "<none>" (for some pulldown choices). The string is in HTML tag pattern "<tag>". Inserting "<div>eclipse123456:</div>" instead does not hurt in this case, but not very pretty. Can anyone think of a better solution?
reopen
Link to a sample PDE editor HTML snipet string: http://babel.eclipse.org/babel/translate.php?project=eclipse&version=3.5&file=pde/ui/org.eclipse.pde.ui/src/org/eclipse/pde/internal/ui/pderesources.properties&string=OverviewPage_content
(In reply to comment #2) > I cannot think of a simple solution. One workaround may work, but not fool > proof. When we see string begining with the HTML tag pattern "<tag>", we insert > "<div>eclipse123456:</div>" instead. This seems to solve the PDE editor > problem. But, I've seen strings like "<none>" (for some pulldown choices). The > string is in HTML tag pattern "<tag>". Inserting "<div>eclipse123456:</div>" > instead does not hurt in this case, but not very pretty. > > Can anyone think of a better solution? I think that this would be acceptable ... the <none> pulldown choice is not the common case, and I think it is important that we can verify Forms (which PDE uses). PW
Created attachment 130701 [details] PDE editor I think this form text problem is very specific to PDE. I don't recall seeing something similar to this elsewhere. Therefore, instead of matching any HTML tag and perform this workaround, I'm thinking to look specifically for the "form" tag. (We will deal with other HTML tag cases if the problems come up later.) A few more twists needed for the fix: - placing "<div>prefix</div>" at the beginning of the string, before form tag, resulted in a message from a FormText class saying the text is non-well-form; I have to move the prefix as the first child of the form tag - the prefix does not show up if it's enclosed by the div tag; I changed that to a p tag, then it shows up Comments on the fix, Denis, Antoine?
That seems OK. Note that those strings in the PDE editor have been like that forever.
Created attachment 130704 [details] patch
+1
I've released the fix to CSV. Coming Sunday's weekly build probably will not include the fix yet (until we deploy the fix to the live server). Please test with the following test update sites: http://build.eclipse.org/technology/babel/test-updates/galileo/ http://build.eclipse.org/technology/babel/test-updates/ganymede/
