grep "foo.bar="
That's the point: you have to keep sticking conditions in there as you encounter problems. And, what if there are spaces around the equal sign? A bigger and bigger regex for each new variation encountered.
And a text resource file can't? You're stretching.
I know that most languages can reference the common RDBMS. I don't have to keep reinventing the same parsing in different languages.
Ah, your vast experience doing internationalized systems. I see.
Just because you've done one or two does not mean you have encountered all possible request permutations.
Ah, so now you're maintaining TWO databases for the sake of this labor-saving scheme of yours. Got it.
Coupling to your favorite everchanging frameworks is not always labor-free either.
Because the changes are being checked in and managed by me, not the guy on the other end of the wire whose only talent is converting English into Swahili.
Well, then it is not a "large project".
So just exactly how does this system of yours work? Or haven't you thought it through properly? Does it issue a single select? "Not necessarily." Does it cache them on the first hit? Who knows. Does it cache them for each page? Can't tell you.
The optimum solution depends on a lot of things, for example whether we are using a dynamic or static language, whether performance is more important than developer labor, whether it is web-based, etc.
"hard to find" Care to back this up? They're right there in the same place as the JSP files that use them, as opposed to way off in database land, completely unrelated to the code that references the messages.
So lets put everything in code and forget databases. New employee? Don't put them into a database, but rather code up an XML file. Replace Oracle with XML. Yeah, that's progress.