From: Anna T. \(atalis\) <at...@ci...> - 2006-07-20 19:16:49
|
Felix,=20 > > A project I'm working on has an existing, not internationalized > > codebase. We are going to use Gettext Commons in the=20 > upcoming release. > > All the new code is supposed to have tr* wrappers in it,=20 > but we'll still > > need to deal with the existing code. >=20 > Nice. If it's a public project, could we maybe point to it as=20 > an example of=20 > how the Gettext Commons are deployed? It's not a public project - it's one of Cisco's management applications. :-( =20 >=20 > > We need to get a list of unwrapped strings so that we could=20 > go through > > the code (automatically or manually) and wrapp those strings. >=20 > If you wrap the strings manually, you don't need to extract=20 > the unwrapped ones=20 > beforehand. After you wrapped them with i18n.tr, they can be=20 > extracted by=20 > xgettext. Am I missing something? The old code wasn't written with i18n in mind and has no wrappers around strings at all. We are trying to find the most efficient way of identifying and wrapping strings that need to be externalized. Going file by file manually and checking whether there's anything to externalize there would not be most efficient, so we are trying to automate it. A possible process would be: - Get a list of all non-externalized, unwrapped strings in the code using a script (something along the lines of what you are suggesting below). - In the list, identify strings that do NOT need to be externalized. - Tag them in the code manually to NOT externalize them (the assumption being that percentage of such strings is going to be small). - Run a script to wrap all the remaining strings in the codebase into tr() methods automatically. >=20 > > I see=20 > > that one can extract either all strings (-a option) or tr*-wrapped > > strings (-k*** options). But is there a way to extract all strings > > *except* those wrapped into the tr* methods? >=20 > You could use a couple of regular expressions, or extract all=20 > strings with=20 > xgettext and then extract only the tr() wrapped ones and=20 > subtract the latter=20 > set of strings from the first one. Or maybe you have a point=20 > in time in the=20 > history of your source control system when only unwrapped=20 > strings existed? It looks like we'd have to write scripts for that. I was just hoping someone already did that. :-( >=20 > > Also, do you know of any tools that would help us to wrap unwrapped > > strings automatically? >=20 > We still have plans of writing an Eclipse plug-in for this=20 > purpose. It would=20 > make use of the Java Parser of Eclipse to detect the strings=20 > and refactor the=20 > code properly, similar to what "Externalize Strings" does for=20 > Eclipse's way=20 > of i18nizing. That'd be great! We'll be using Eclipse-style NON-NLS tags to mark strings that don't need to be translated anyway, so a plugin like this would be very handy. We are not going to support i18n in the release we are working on right now because of resource constraints. We are just laying the framework to, hopefully, reduce the amount of work we'll have to do eventually. Perhaps this Eclipse plugin would be done by the time we are ready to use it (which would be in several months). That'd be very useful! Thanks for your time, Anna |