>string was replaced in the code with a unique ID and the string (and ID) >was written to a textfile which was then sent off for translating. When the >translated file returned the opposite action was performed. The translated >strings were "stuffed" back into the code. I'm sure all the shortcomings of >this approach should be obvious and don't need reiterating. > >Does anyone have any experience with this sort of problem. If so, I'd >appreciate hearing about possible methodologies and any associated >drawbacks. > >Thanks in advance .. I've used a slightly different approach - my ScanTxt routine created a table (strings.dbf, of course :) from all the strings found, and immediately asked for a transcription; it was stuffed back into the line where the string was found, and the processed file was saved under the same name, date and time into a subdirectory. The table remained for the transposal of the next version, so once it was necessary to propagate changes to the original version, it reused the old transcripts, and prompted for new ones only. The drawback was that it wasn't perfect enough to know all the situations when it should or should not keep or trim the leading/trailing blanks, or when is the transcript allowed to be longer than the original. Another one was that various names are passed as strings, and sometimes those names are official words within the app, and at other times they are words to be translated - the trivial example being "Customer". It may be both a table name passed to a routine and a column header in a report. I was lucky to have a non-English language for the app, so cases like that were very seldom (but also harder to find). This could be refined with some "translate in this case and don't translate in another one" logic, but it takes too much time to run - as for the programming part, it's kind of easy, there's Where.dbf which says exactly in what file at what position the string appears, so it's easy to implement the dos and don'ts - it's hard to watch the screen all the time and track them. Now in VFP the situation may be a bit easier - if all the strings which are visible to the user are #defined or put into properties like ..caption or .tooltip; if the strings are to be chased around the method and other code, it might become a nightmare - it will find too many strings (all the parameters to DbSetProp, SQLexec etc). I do have another utility, AddLang, which searches a .prg for all the possible stings, and creates #defines for the ones user chooses, and replaces their occurence with c_variables - unfortunately it's still in FPD version, so it'd have to be adjusted for coping up with the method code. Once it finds all the strings, it makes #defines for more languages, and prompts for the values for all of them, but then it's a one routine at a time job. I do that for system routines only, and it doesn't keep the strings found in any table - it uses a cursor and forgets on exit; next time it reads the #defines and restores the values from there. The up side is that it's trivial to add another language - just add a field to the cursor, and re-run it on the prgs. If anyone's interested enough, we may start working on a VFP version (email me). The problem I don't know how I'd solve: is it possible to have a #defined constant for a property value, like this: #define c_caption1 "Caption text" and in the properties Caption=c_caption1 If this is possible, where'd I put the #define - to the top of the methods' memo in the .vcx/.scx, or where?