More than two languages could be of use for people who translate from a given script into a third language. If you are going to use language tags though, please don't make stuff up, but use ISO 639 codes and use them as defined by BCP #47 (best current practice #47). For instance, your example contains en for English, yet jp for Japanese whereas it should be ja for Japanese, because JP is the country of Japan. This confuses people and decreases interoperability.

Also, don't forget versioning. Version all your XML files, so when you parse them you can give a version error instead of failing or crashing. So when the underlying XML grammar gets changed within the stability requirements, you will still be able to parse it correctly for the most part, but can give an error if the grammar version the file was produces with isn't supported by an older version of the program for instance.

All Atlas-specific data can be stored in tags as well, so don't leave that out either. Also, user-defined fields that don't pertain to Atlas in any specific way might be desirable so people can use the files outside of an Atlas context and store information that is relevant to them in there. Of course there might be other standard fields that could be defined for Atlas to insert in a special way, for instance "speaker" would be such a field. Helps the translator if it's known and games that do show this info can have their script inserted in the right fashion by Atlas with this info if the format for said tag is provided.

cYa,

Tauwasser

Just finished a (very) WIP build.  There are a few discrepancies vs what I'd like to see, but that's partially due to coding difficulties.  The GUI is very much WIP too...it'll be more developed when more details are worked out.  At the moment, it handles Atlas files (stripping the comments for now) and basic scripts (hardcoded string delimiter of "<END>" at the moment).  I included a sample script (FF1, english dump) since the combined J and E text files I have, I can't release (though, I do have them working in a separate build, since it requires a slightly different parser).  You can run the FF1 script yourself and it'll generate a generic XML file.  It automatically uses the xml2excel.xslt file I made (first one, too), to generate a SpreadsheetML .XML for Excel (contains a few hardcoded items, which'll be phased out).  It does, however, hide all Atlas commands (the entire column as well as rows) by default, something that might change.  Especially when I get around to more VBA.  Ensure your text encoding is Unicode/UTF-8 if you are using a Japanese script, else it won't show up in Excel.

You can download the WIP from: Script2Excel

I'm worrying about working code first.  I really don't care about the difference between ja and jp when there's no really code to support it yet.  And of course the spec would support multiple languages (in one document, even).  If the translator doesn't want to view the other languages, he/she can just right click the column and hide it.  At the moment it uses <sourcetext> (which is kinda meant to be from a dumper, but it works too) and eventually it'll be something like <sourcetext lang="en">.  There's a lot of options to organize and nothing is set.

I couldn't get XmlSerializer to output proper line breaks for inside of nodes for Excel (which is &#10;...which gets interpreted to &amp;#10;), so I wrote a quick macro to properly resize the row heights without unhiding the Atlas commands.  You'll first have to enable word wrap on the column you're resizing the rows of.


Once we get the form down some, we can probably start testing Google Docs (which can import/export Excel files) to see if my proposed benefits materialize.  The XML is still admittedly ugly, but I just wanted to put out a proof of concept, which wasn't that hard to do.

Haven't decided upon how to store the conversion settings as these will vary depending on the target program.  In any case, the user will be able to provide an XSLT file for transforming the standard XML to a target program (probably just modding the supplied XSLT).  The current UI is just a test interface.  A final UI would definitely prompt you so that you won't overwrite a script file by accident.

So the next step in this process is to develop a DTD (Document Type Definition) or XSD (XML Schema Document) to draft the XML more clearly for review (so my program will follow the spec, rather than the spec following my program).  Does anybody have any input on which should be used?  I used DTD back in 2003, but I don't know which of those two routes I should go as I'm not a regular in the XML world.

Sorry for the delayed response.  I didn't see the new post.

At the moment, there has been no new progress due to a relative lack of interest in the project.  I am currently playing around with a test project and once I figure out the text encoding and/or compression scheme on it, said game will be used as a sample to help iron out design issues in the spreadsheet project (and to pretty it up some).  I wouldn't expect an official release for at least another two months if things are going well.  I'd hate to release a program that creates an Excel spreadsheet, have someone use it to translate a script, then realize that some feature of Excel they used breaks the conversion process back to plain text.