Community
Participate
Working Groups
<response_by> Eriko Takahashi at 2008.05.15.09.12.19 </response_by> OS: Linux Build date: 0514 Component/Functoin name:WTP Blocking:NO Language: Japanese Tester Name: Eriko Takahashi Steps to recreate the problem: 1. Create Static Web Project. 2. Right click on the Project created, and select ?Properties? 2. Expand the JavaScript node. 3. click on Javascript Libraries 4. Click on Global Supertype tab Problem description: The description in the field at the very bottom of the Global Supertype tab says "*** in xxx" (eg. "Window () in ECMA 3 browser support"). I believe "***" and "xxx" part are externalized, but not the word, "in". Could you provide the text, "*** in xxx " as one string so we can translate it properly? Thank you. Eriko Takahashi <response_by> Matthew Mazaika at 2008.05.15.13.43.17 </response_by> This article was reassigned from Category:''TVT/Testing,Inbox''.
Created attachment 100528 [details] 3.001580_ja.gif
<cde:tctdetail> Testcase: 3.001580 Project: WSW34 Component: Xfer - Web Tools/jst.server Priority: 3 Subject: JA: "In" in English in JavaScript Library ->Global Supertype panel Article ID: 289 Originator: ERIKOT@jp.ibm.com </cde:tctdetail>
Moving to correct component.
<response_by> YoungSun Ko at 2008.05.21.09.14.47 </response_by> Same for Korean. thanks, Youngsun
Created attachment 102670 [details] patch to externalize "() in" string
i've updated with a patch. i don't believe this bug's severity is major or that it's necessary for 3.0. i'm going to move severity to normal and target the fix at 3.01
Re-targeting/requesting PMC approval for 3.0RC4 per request of Cam-Thu T. Le (camle@us.ibm.com) on June 04.
looks ok to me
I think we need to get in all the "externalized string" problems we can, as that leaves the code in an "untranslatable state" until it's fixed. And ... there's already a lot of "lead time" required for translations. This will help the Eclipse Babel Project be able to do what it needs to (based on community participation), as well as any specific adopters that want to do translations. And, IMHO, we often under prioritize these issues, because, after all ... we can read them :) (that is, it's hard for many of us to empathize with non-English speakers.).
Patch applied to HEAD. Thanks.
Bradley, please note that for RC4 it is required three positive votes by PMC - not two. I see a problem with the proposed patch. It still maintains the bad i18n practice. This is the proposed fix: - return superTypeName + "() in " + getLibraryName(); //$NON-NLS-1$ + return superTypeName + Messages.getString("LibrarySuperType.0") + getLibraryName(); //$NON-NLS-1$ +LibrarySuperType.0=() in A much better solution would be: - return superTypeName + "() in " + getLibraryName(); //$NON-NLS-1$ + return Messages.getString("LibrarySuperType.0", new Object[] {superTypeName, getLibraryName()}); //$NON-NLS-1$ +LibrarySuperType.0={0}() in {1} This way you give the freedom to the translator to change the order of words in the whole string if needed. It is almost guaranteed that there is a language on the earth that will require this.
Bradley, please go on and correct your latest changes in CVS. Just make sure that you attach the new patch in bugzilla, so I have a look at it.
Created attachment 103800 [details] better patch using best practice as suggested.
Comment on attachment 103800 [details] better patch using best practice as suggested. great
applied patch.
<response_by> Matthew Mazaika at 2008.06.13.09.23.31 </response_by> It doesn't look like this will make it in by the end of TVT. It may make it in for 3.4, but will most likely be deferred until the first maintenance release.
