Quote:
Originally Posted by eureka
OK, so there are two tasks for now: dealing with resources in JavaScript files and in Java .class files. Which one would you like to take? I'll take another one then. (Anyway we'll end with one tool written in Python.)
|
If you're ok with it, I'd focus on the Java part and let you look into the JS part. That way, we should end up with better quality tools for both (the prior resource extraction script was just a hack, the new one does it in a much better way; and it's better to use a proper JS parser than just regexes).
Quote:
Originally Posted by eureka
Looking at output of your tool I've received an insight: there could be no need in original .js and .class files for constructing of translation.
JS strings are always in one format: there is one variable contained object with a strings and with other objects, which are contiaining strings or other objects... As in .properties we have name of object and it's keys ("PasswordDialogStringTable.passwordEntryTitle" or "bapp.strings.error.na"), we could construct JavaScript file from the ground-up. It will looks not the same as original file, but will return the same result.
|
Good idea, and would probably work for the Java part. for JS I'm not entirely sure. As I mentioned in one of the posts above, there is at least one instance where there is actually JS code instead of a simple string, using a MessageFormat (or something the like) as the value. Maybe we can simply keep the *entire* value as the property (so e.g. for strings, including the simple, or double quotes around it. For potential "real" JS code, it is then up to the translator to make sure that what they commit is still valid JS)?
Quote:
Originally Posted by eureka
Though, I can't say definitely could .class files be reconstructed from .properties in output format of your new parser, I hope it is so.
The advantage is absence of Amazon code in repository.
|
As to not having Amazon code in the repo: definitely a good idea.
For the (new) Java props parser, the "finding" part is actually real easy. I simply find all classes which extend ResourceBundle, and then use normal Java to get the actual properties (getKeys/getObject). No parsing needed.
For writing back changes, I took a look around, and SERP (
http://serp.sourceforge.net) looks good. (Other alternatives:
http://java-source.net/open-source/bytecode-libraries). I'll see what can be done when I get to it (as announced earlier, I'm shorter on free time now... maybe over the weekend).
Concerning the md5sums, I'll check 5.0.1 ones tonight.