I18N

Post #156,630 by admin 5/24/04 12:50:01 PM Reply	I18N All that link to the Internation UI Example showed was your inability to grasp the issues. "Bottom" is right... using a database over text files gives you no benefits, and results in a loss of efficiency. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,641 by tablizer 5/24/04 1:48:02 PM 5/24/04 2:15:41 PM Reply	You are WRONG! All that link to the Internation UI Example showed was your inability to grasp the issues. Name calling? I don't appreciate that in the slight. I take big offense to that. Fuck you! If you have slam-dunk evidence then show it shove it! "Bottom" is right... using a database over text files gives you no benefits, and results in a loss of efficiency. If one has the option of using tables to generate "resource files" or whatever you want to call them, then the compiler does NOT CARE where they came from. It is not going to say, "Oh, these resource files were auto-generated from DB tables; therefore, I will run them slower". That is outright silly! That is a PHB-style mental error. I personally don't want to manage boatloads of messages as programming language files. Databases were created to help people track and manage boatloads of attributes, and that is just what international message info is. You are not going to tell me how to best manage information that I have to work with. Sure, a boss can dictate to me how to organize such info, and can even dictate to me how to organize my desk and pencils and paperclips. But, that does not necessarily make me more productive. Having them in tables allows one to sort by language, sort by message (ID), search for similar messages, print reports that non-programmers understand, etc. The presentation becomes untied to a programming language grouping or file organization. Sure, if it is a small application and there are only a few target languages, then editing within code files directly is fine. The bottom line is that code makes a shitty database. ________________ oop.ismad.com Edited by tablizer May 24, 2004, 02:15:41 PM EDT Expand All History
Post #156,648 by admin 5/24/04 2:31:42 PM Reply	My my, I touched a raw nerve, apparently. Where's the name I called you? From the link: Top: I am trying to think fairly large-scale here. What if "last" is used to mean both "previous" and "final" in different circumstances in the application? Bottom: The word "last" can be used in many different circumstances in the application. Top: A simple content look-up will not work. Bottom: It will and it does. The word "last" isn't looked up by itself. The phrases "Enter last name:" and "Your glory shall last" each have their own separate translation. It doesn't matter that the same word appears in each English version. It's pretty plain to me that you don't understand the issues here. Hence your confusion in the conversation you linked. How is this name calling? I personally don't want to manage boatloads of messages as programming language files. Neither do I. That's why I use resource files. You are not going to tell me how to best manage information that I have to work with. And you have done how many internationalized sites? I thought so. Yet you still feel qualified to tell everyone that your approach is so much better, even though it just solves problems that don't exist. "Bottom" is right. People don't need the sorts of "reports" you're talking about. Having them in tables allows one to sort by language, Er, and this can't be done with resource files for what reason? sort by message (ID), Why would anyone want to do this? You don't understand the problem set. search for similar messages, grep is your friend. print reports that non-programmers understand, etc. What kind of reports? This stuff simply isn't needed, and your over-engineered "solution" is more work for no gain. code makes a shitty database And databases make shitty code. Now change your tone or this conversation is over. I've been perfectly civil to you and I don't appreciate your response. You're acting like a sore loser. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,679 by tablizer 5/24/04 4:24:23 PM Reply	Grep is no substitute for clean, normalized data It's pretty plain to me that you don't understand the issues here. The context of that has appearently been deleted. Some were proposing translations using phrase look-ups. Even the links given did not use direct phrase lookups. How is this name calling? You accused me of "inabability to grasp the issues" without giving specifics. Even if true, the diplomatic way to say it is, "I beleive you are incorrect with regard to point X" rather than some sweeping generalization. Your people skills are even worse than mine, and that is saying something. I've been perfectly civil Bull. See above. Even if you think somebody is a total retard, it is improper to inform them of such judgement. One should point out specific things to complain about, not sweeping or vague generalizations. If you know of a specific use-case that busts my proposed solution, you are by all means welcomed to produce it. grep is your friend. That is a hacky approach. Tables are safer. Neither do I. That's why I use resource files. Hardly better than source code files. Why would anyone want to do this? You don't understand the problem set. That is nature of the biz world: you cannot predict ahead of time how somebody is going to want to see/query something. And databases make shitty code. Translation lookup tables are not "code". Even the VB resource file example calls them "tables". ________________ oop.ismad.com
Post #156,685 by admin 5/24/04 4:35:47 PM Reply	Re: Grep is no substitute for clean, normalized data That is a hacky approach. Tables are safer. That is a general statement. Provide specifics. Hardly better than source code files. In what way? They're a specific solution for a limited problem. some.string=The specific string for a message. How is the above "hardly better than source code"? I'll go you one better, in fact: how do you maintain database information over revisions? Keeping this in the database isn't sufficient when you have several database environments (Dev, Test, QA, Prod for example). Text resource files are amenable to revision control via common source code control tools. Translation lookup tables are not "code". And neither are resource files. That is nature of the biz world: you cannot predict ahead of time how somebody is going to want to see/query something. Especially if you've never done an internationalized application, which I'm guessing (by your non-response) that you haven't. Those who have understand that this simply isn't a requirement. You're inventing problems in order to provide your "solution". And since your solution adds extra complexity in the form of database access (or code generation) for no material gain, it is inferior. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,696 by tablizer 5/24/04 5:00:31 PM Reply	Depends on the scale {That is a hacky approach. Tables are safer.} That is a general statement. Provide specifics. 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. I'll go you one better, in fact: how do you maintain database information over revisions? Keeping this in the database isn't sufficient when you have several database environments (Dev, Test, QA, Prod for example). Text resource files are amenable to revision control via common source code control tools. 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. See below. I am just too damned far ahead of my time :-) Especially if you've never done an internationalized application, which I'm guessing (by your non-response) that you haven't. Those who have understand that this simply isn't a requirement. You're inventing problems in order to provide your "solution". And since your solution adds extra complexity in the form of database access (or code generation) for no material gain, it is inferior. No, I have not done formal internationalization. But, how large was the project(s) you did? A tablized solution probably would not be practical unless you have say 20+ languages and 1000+ messages (per lang). Files are fine for smaller stuff. I never disputed that here. I am pretty sure there is a size-point in which you agree that files won't cut it anymore. For example, suppose most of the translators work offshore (which is expected for language translation). One may want a web-site where they log into and review and change messages. Doing that at a file granularity is a bit messy. Through such a portal we can fairly easily track which messages were changed by who and when. That can be done with files, but it takes a lot of Diff commands. 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. ________________ oop.ismad.com
Post #156,703 by FuManChu 5/24/04 5:15:10 PM Reply	You've never used CVS either, have you?
Post #156,711 by tablizer 5/24/04 5:50:18 PM Reply	No, only MS sourcesafe ________________ oop.ismad.com
Post #156,714 by admin 5/24/04 6:02:42 PM Reply	shudder I used Source"Safe" once. Just once. It ate the repository. What a piece of cack that program is. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,809 by tablizer 5/25/04 2:10:39 AM Reply	Not my pickings ________________ oop.ismad.com
Post #156,710 by admin 5/24/04 5:48:35 PM Reply	Re: Depends on the scale 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. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,719 by tablizer 5/24/04 6:19:48 PM Reply	no no no grep "foo.bar" finds all instances of the "foo.bar" message. Yes, but if you have "x = 'my foo bar is here'", it may also pick up that message. and in fact has some disadvantages as I have named Very minor. And the message tables can be used with other languages and systems. Once the bulk job is done, changes will be minor and are best handled through existing revision control tools. In my experience, vast change requests may come out of left field so that there is a lot of rework to be done. And I certainly wouldn't give a bunch of people located off-shore access to a database used by the production system. You don't give them database access, only access to a web application. And, it does not have to be a production system. Besides, why is file access safer than database access? A file system is a database, just not a relational one. Something that large isn't using XBase, I can guarantee you. And they are bulkier and harder to use than resource files. I am not necessarily talking about the production application language. One can build tools in a different language than final applications. 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. You got it all wrong. Each message does not necessarily issue a Select statement. 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. So we should chuck databases and go back to flat files to manage everything? How 1960's of you. The bigger the project, the more a database HELPS! Keeping tons of attributes in a bunch of hard-to-query and hard-to-find flat files is really annoyining. How about this. We start out with a file-based approach. If message management becomes a headache, then we DB-tize the config file generation. Deal? ________________ oop.ismad.com
Post #156,721 by admin 5/24/04 7:02:50 PM Reply	Re: no no no Yes, but if you have "x = 'my foo bar is here'", it may also pick up that message. `grep "foo.bar="` And the message tables can be used with other languages and systems. And a text resource file can't? You're stretching. In my experience, vast change requests may come out of left field so that there is a lot of rework to be done. Ah, your vast experience doing internationalized systems. I see. You don't give them database access, only access to a web application. And, it does not have to be a production system. Ah, so now you're maintaining TWO databases for the sake of this labor-saving scheme of yours. Got it. Besides, why is file access safer than database access? A file system is a database, just not a relational one. 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. You got it all wrong. No, it's called "covering all bases" since you're being so vague about "might" and "doesn't necessarily" and so forth. You oh-so-conveniently didn't quote "And if you cache them, that's more coding and database maintenance overhead just to match the same functionality provided by resource files." 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. So we should chuck databases and go back to flat files to manage everything? How 1960's of you. The bigger the project, the more a database HELPS! Keeping tons of attributes in a bunch of hard-to-query and hard-to-find flat files is really annoyining. No, but they're damn nifty for internationalized messages. How very binary of you. "hard to query" Er, no. Got grep or find? Got an editor? Everyone does. Better that than "oh, to work on the messages you need to set up ODBC like so, and install Access, and search for them here like this. Oh, wait, you wanted to see the messages in QA, not DEV? Well, you need a different ODBC source then..." Seems to me the database version is a lot more of a pain in the ass for someone who just wants to edit a bit of text. "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. Seems to me the database version is a lot more of a pain in the ass for someone who just wants to edit a bit of text. How about this. We start out with a file-based approach. If message management becomes a headache, then we DB-tize the config file generation. Deal? What's this "we", Kemosabe? Message management hasn't become a headache yet. You've not demonstrated that it will be, and given that you have no experience in the matter... and since I'm working on a system right now that has nearly 2000 similar text resource files, I'll keep my own counsel on that one, capicé? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,724 by ChrisR 5/24/04 7:13:59 PM Reply	Doing my part to promote right shifting Perhaps you've already explained in this thread and I missed it, but..... Was wondering why your putting internationalization in the board. I've been putting off internationalization in my current app, mostly due to Sarbanes-Oxley being U.S. centric. Sooner or later I'm going to have to tackle it, as some of our customers have to get sign offs from far away lands (europe, china, etc). So I fully understand that it is a requirement for a lot (if not most) business apps these days. Just wondering what you are trying to leverage on zIWETHEY? (For example, does it make Nadsat or Guido easier to implement?)
Post #156,728 by tablizer 5/24/04 7:24:31 PM Reply	"Oh goody, a new framework for xmas!" Was wondering why your putting internationalization in the board.....Just wondering what you are trying to leverage on zIWETHEY? Isn't it obvious?: To make competing with his features harder for me. His whole life revolves around kicking p/r's ass :-) ________________ oop.ismad.com
Post #156,731 by admin 5/24/04 7:27:18 PM Reply	Re: "Oh goody, a new framework for xmas!" His whole life revolves around kicking p/r's ass Not really. I do that before breakfast and then go on to get real work done the rest of the day... ;-) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,730 by admin 5/24/04 7:25:32 PM Reply	Internationalization (new thread) Created as new thread #156729 titled [link\|/forums/render/content/show?contentid=156729\|Internationalization] Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #156,734 by tablizer 5/24/04 7:38:16 PM Reply	admin 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. ________________ oop.ismad.com
Post #156,742 by admin 5/24/04 8:02:47 PM Reply	Resource files (new thread) Created as new thread #156741 titled [link\|/forums/render/content/show?contentid=156741\|Resource files] Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."

Welcome to IWETHEY!