> I volunteer to do some proof-reading, and also to translate to Norwegian > (eventually even to Danish and Swedish, if noone else is doing that).
Translation is very welcome, but it requires some work, so I think that Norwegian is good for starting. > I know I've previously volunteered to produce documentation, but that has > been difficult since I don't quite know what the program can do (other > than what I use it for), and neither what it's supposed to do when it's > finished. So I have actually been intending to write and suggest some > translation work, since that is an excellent way to get to know a > programme. Yes, I agree, translation work is a good start to gather knowledge about the features and the philosophy of Scidb, the quality of the translation depends on the real understanding of the message items, and this depends on the understanding of the documented feature. > I'm thinking: the only way to be able to write documentation, test, etc., > is to really know the program quite well, and the only way to get to know > the program really well is to use it on a day-to-day basis. Thus, I'd > suggest to give some priority to the aspects of the program that the user > will be likely to use: shortcuts and navigation, basic functionality (such > as e.g. filtering of the database), etc. That, to me, is much more > important than even more chess variants or opening book formats. This is a difficult thing: 1. Different users have different priorities, I know a user who is keen on the opening books. 2. Developing Scidb is something like a hobby, I do this for fun, this is my highest priority. So I'm always working on that task which is currently the most interesting one for me, this is changing from time to time. But I have always in my mind that some features are the most wanted ones, especially navigation and filtering (one of the most ambitious tasks). 3. Some of the features are very time consuming to develop, so I'm always waiting for an inspiration how to design and implement a specific feature, and I'm never staring before I have an inspiration. This is the way how I can realize this application in such a short time (with about 1.000.000 lines of code, and about 100.000 lines of documentation, if related projects like C/CIF will also be considered, as well as all the code which I have thrown away - sometimes more than one idea is required until the "prefect" idea is coming). And it's not only design and implementation, also the documentation (in two languages) is very time consuming. (BTW: I've learned English as I started to write the documentation for Scidb, I never been a linguistic genius.) About shortcuts and navigation: here I need suggestions from the testers, but please consider that different users have different ideas, and I'm realizing those ideas which fit best to the basic philosophy of Scidb, and Scidb is going his own way. BTW: I'm keen on the integration of the chess variant Congo Chess, this variant is quite amazing, invented by an eight year old child. Also Dobutsu Shogi is very interesting for children. BTW: I've forgotten one of the future features of Scidb: - Support of children's chess, this means allowing and supporting invalid moves, like Nb1-b3. This requires a special treatment in move encoding/decoding (already integrated in the new database version). The children chess support will be optional, without explicit support input of invalid moves will not be possible, so it has no impact on the "adult" chess. ------------------------------------------------------------------------------ _______________________________________________ Scidb-users mailing list Scidb-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scidb-users
