You generally don't have to parse to isolate the "atoms". Unless you always provide a perfect parsing specification, there is a chance of getting it wrong. The "walls" are predefined for us so that we don't have to find them over and over.
foo.bar=Foo the bar\nmoo.gar=Moo the gar
grep "foo.bar"
finds all instances of the "foo.bar" message. You're inventing problems where none exist.I will agree that the existing crop of revision control tools are designed for files and not databases (although I have not done a survey yet). However, tables make it easier to roll-your-own. Plus, one can have more control over individual messages.I'm not interested in "rolling my own". I'm interested in getting work done. If your approach provides no tangible benefits, and in fact has some disadvantages as I have named, why in the name of seven Hades would I "roll my own" just to get to the same level of functionality I already had?
I am pretty sure there is a size-point in which you agree that files won't cut it anymore.I don't see why. One file per message set per language. No overhead. If it's farmed out, give them the English version and say, "translate this". Once the bulk job is done, changes will be minor and are best handled through existing revision control tools. And I certainly wouldn't give a bunch of people located off-shore access to a database used by the production system.
The management becomes harder the larger the system becomes, mainly due to the multiple environments I mentioned.
You also make it sound as if tables are hard to use and bulky for internal stuff. Somebody used to XBase stuff will generally disagree.Something that large isn't using XBase, I can guarantee you. And they are bulkier and harder to use than resource files.
Here's an example:
\n<bean id="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource">\n\t<property name="basename"><value>Messages</value></property>\n</bean>That's what I do in the config file to load my resource files. When I want to use a message, I do this:
<fmt:message key="some.key"/>That inserts it into the JSP file. Whoopdee doo, that's so incredibly hard. I must be high if I think that's better than a bunch of SQL select statements.
And calling into a remote database for thousands of strings isn't practical. And if you cache them, that's more coding and database maintenance overhead just to match the same functionality provided by resource files.
Pre-compiling involves the database in the compilation step, which is also useless overhead and harder to manage.
Have you actually worked on a large-scale system? Say something with a few hundred tables, a million lines of stored procedures, and millions of rows of dynamic data? The kind of thing you're proposing introduces unneeded, unwanted complexity into an already complex system.