Thank you for correcting the English translation!
You're welcome, but that's just one first step, I expect this will have to be refined as I get familiar with the whole thing ^^
More on this all throughout the post.
Very good points.
The script knows nothing about specific locations of data, but lists and scans the whole cd-images for "known" file formats to extract (see example image).
So how can one do anything useful with such rcdata, while other rcdata contain something else?
Could you write 3 of functions for it?
1. Read a portion of data from the file (name) provided and sample the extracted data to determine if the file contain data that can be extracted in an orderly fashion
2. Read and if needed separate data from garbage to be entered to the translation database
3. If present in the target language, extract the equivalent translation to complete the from-to translation pair, otherwise it will translate online and indicate that in the database.
rcdata as file format allow for a vast variety of content.
I'd need structural info to know where to add it to the large script:
Would your code perhaps handle data as "osapplet"? (or suggest other, one per file-format-handler-function to call)
Some file formats contain translation pairs, others in separate files with the same base name, while yet other on the same location in each cd-image. I assume that these rcdata text is of the latter.
Mmmh, let start with the coding part. IBM's RCDATA blobs which are just heaps of strings are very easy to parse. Example: save the strings.cmd attached, extract the famous resource #5000 from PMWPMRI.DLL with "resmgr -x PMWPMRI.DLL 5000 mystrings.bin" and process with "strings.cmd mystrings.bin" or "strings.cmd mystrings.bin > mystrings.txt".
As for the question of what string blobs to parse like this, or leave alone, I have no easy answer, there may be none. You could try some heuristics (f.e. if an rcdata blob contains only text data, i.e. charcodes >= 32 strings followed by short null terminator runs --ideally single nulls, mybe two at the end-- it very likely is a string "heap"), but not even that will tell you much about what to do with what you get. By this I mean that after processing you could still have anything: a string array where stuff will be picked by index (so check for equal array length on both sides of the translation), or some table. For example, take glocmri.dll. As all MRIs, this says 'translate me'. However, there you will find an rcdata string blob that will translate to a table of language codes and names; one column should be translated, the other not. How to tell programmatically? How to tell it is even a table?
trn_es.txt changed id 47 set to: Espa¤ol
OK, but you did it on an editor that changes OS/2 newlines (CR+LF) to unix-style ones, please see the attached pic and do it again ; )
Anyway, this brings me back and full circle again onto the most important question, as often overlooked in translation projects.
How would I know that message #47 should translate as "Español" and not "English"? There is no way even the best translator in the world would, except by familiarity with the project, knowing where translations will end exactly, and probably having a couple of goes at it.
The problem is, stuff like the above, which any translation database project will inevitably keep bumping into, is extremely difficult to handle, let alone get right, in some generic way -- it will take time and familiarity with project specifics, so please take this is as a very friendly warning to be patient and persevere. We'll get stuff out of the way, one step at a time. : )