| Internationalization (Externalization) [message #284336] |
Thu, 21 April 2005 08:00  |
Eclipse User |
|
|
|
Hi,
I've a question regarding externalizing Strings in a project using
Eclipse's built in Externalization wizard.
I'm not sure how it is intended but the way it can be done now looks very
unfortunate. It looks like you are supposed to externalize on a package
level. This introduces a couple of problems I don't know how to address:
1. the properties files look like they are supposed to be part of the
resulting jar file. This makes translation without rebuilding impossible.
In our organization, translation and documentation is done by a separate
department, sometimes even after production of the software.
2. each package is supposed to have its own properties file. While this
reduces the possibilities of name clashes, it disallows reusing common
text like Delete, Discard, New, etc. from a central properties file. I'd
rather deal with name clashes via prefixes than having hundreds of
properties files.
3. The current solution doesn't seem to offer support for getting Strings
from multiple properties files from within the same Java class.
4. The externalization wizard resets back to the same default settings
each time you open it. This way, you have to point it to the same central
properties file over and over again for all your Java files. This means
that you do the same configuration settings a thousand times in a project
- tedious to say the least.
Did I misunderstand the whole externalization support or do the above
limitations really apply? Is anybody using the current support to any
level of success? Is there a way around these problems (I'd be already
happy if we could set the externalization wizard preferences to something
else).
Thanks for your input on this subject.
Markus.
|
|
|
| Re: Internationalization (Externalization) [message #284476 is a reply to message #284336] |
Tue, 26 April 2005 06:15  |
| Eclipse User |
|
|
|
Originally posted by: carsten.pfeiffer.first.fraunhofer.de
--nextPart2527933.fj0cnCz4EH
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8Bit
Markus wrote:
Hi,
> 4. The externalization wizard resets back to the same default settings
> each time you open it. This way, you have to point it to the same central
> properties file over and over again for all your Java files. This means
> that you do the same configuration settings a thousand times in a project
> - tedious to say the least.
I'm suffering the same problems -- as a start, I hacked the JDT
ExternalizeStringsAction to keep the previous settings. (Not persistant
yet, but at least during one session)
Cheers
Carsten Pfeiffer
--nextPart2527933.fj0cnCz4EH
Content-Type: text/x-diff; name="ExternalizeStringsAction.patch"
Content-Transfer-Encoding: 8Bit
Content-Disposition: attachment; filename="ExternalizeStringsAction.patch"
--- ExternalizeStringsAction.java 2005-04-26 12:07:06.542596721 +0200
+++ ExternalizeStringsAction-patched.java 2005-04-26 12:08:08.747892415 +0200
@@ -51,6 +51,7 @@
public class ExternalizeStringsAction extends SelectionDispatchAction {
private CompilationUnitEditor fEditor;
+ private static NLSRefactoring s_previousRefactoring = null;
/**
* Creates a new <code>ExternalizeStringsAction</code>. The action requires
@@ -144,6 +145,16 @@
private static NLSRefactoring createNewRefactoringInstance(ICompilationUnit cu) {
NLSRefactoring newRefactoring = NLSRefactoring.create(cu);
+ if (s_previousRefactoring != null)
+ {
+ newRefactoring.setAccessorClassName(s_previousRefactoring.ge tAccessorClassName());
+ newRefactoring.setAccessorClassPackage(s_previousRefactoring .getAccessorClassPackage());
+ newRefactoring.setPrefix(s_previousRefactoring.getPrefix());
+ newRefactoring.setResourceBundleName(s_previousRefactoring.g etResourceBundleName());
+ newRefactoring.setResourceBundlePackage(s_previousRefactorin g.getResourceBundlePackage());
+ newRefactoring.setSubstitutionPattern(s_previousRefactoring. getSubstitutionPattern());
+ }
+ s_previousRefactoring = newRefactoring;
return newRefactoring;
}
--nextPart2527933.fj0cnCz4EH--
|
|
|
Powered by
FUDForum. Page generated in 0.02763 seconds
Home