Re: [Kidbasic-devel] Bug, Feature and Translation

[Ian L. <dr...@gm...>]

Hello,

I've changed the permissions on the shell account so you should be
able to write the files that are there currently.

Feature requests:
Filled POLY shouldn't be difficult.  I'd like to re-work the POLY
command anyway so that it uses some type of list, instead of having to
fill an array to use it.  We'll keep the original functionality, too,
but I think it's a bit involved for a simple command.

What this will mean is that a "list" type will be added to Basic256,
or it will be possible to define an unnamed array, like this: [1, 30,
4, 5].  Any additional ideas are welcome.

Sound is a top priority, as soon as I find the time to do it.  Break
points are a great idea that many people have requested, so they'll be
next.  The U/I improvements all sound like good ideas to me, too.

> - The IF/THEN statement could get an ELSE and an ENDIF.

I'd rather not.  I think it's instructive to have to use GOTO as
opposed to higher level constructs so kids can figure out what the
computer's actually doing.

The lisp program wouldn't be as difficult to use as you think.  I can
separate it into two files: the first would be the actual program that
reads and outputs the html, and the second would be the kbcommand
portion that just has the documentation in it.  So the files would be:

generate.lisp (translators wouldn't touch this.)
translation_en.lisp (translators change the English portions to chosen language)

That way, to do a translation you'd just need to copy the
translation_en.lisp and alter any english string.  This would allow me
to change generator.lisp to whatever format I want, and it would still
use the translation without modification.

-Ian



On 12/11/06, Immo-Gert Birn <imm...@gm...> wrote:
> Hello,
>
> thank you very much for your reply.
> Again this will be a longer e-mail. I will write about these topics:
> 1) Feature requests
> 2) Shell access
> 3) Documentation
>
> ad 1) Feature requests
> - The top feature request is regarding sound. At least "my" kids
>   like it to produce some noise with the computer. We discussed
>   this already in a previous mail. I told them the current state.
>   One kid had the same idea that you had: some SOUND command together
>   with some ready to use, short sounds would be sufficient.
> - It would be great if the POLY command would fill the inner
>   areas of the figure with the current color. Maybe there could be
>   a 3rd parameter to the command indicating whether the poly should be
>   filled.
>   But I know that this is not that easy to achieve.
> - The IF/THEN statement could get an ELSE and an ENDIF.
> - Some "break point facility" would be great.
> But overall the kids are very happy with Basic256 and like it a lot.
> Some (minor) UI issues I do still have are:
> - The Variable Window could get a close button. Using the
>   menu is "cumbersome".
> - I would like to be able to select a mono spaced font for the Main
>   Window (the source code).
> - Syntax Highlighting should be switchable (for those that do not
>   like to read colorful code).
> - A Clear-button for the Graphics and the Text Window would be nice.
> - The variable(s) that changed with a program step could be highlighted
>   (for instance shown in dark red) in the Variable Window.
>
> ad 2) Regarding shell access
> You are right, I do have shell access. While I can create new files in
> the htdocs project directory, I can not modify existing ones, as they
> are not group writable:
>   [igb_ppp@sc8-pr-shell1 htdocs]$ ls -l
>   total 340
>   ...
>   -rw-r--r--  1 drblast kidbasic 18458 Dec  8 16:16 reference_de.html
>   ...
>   [igb_ppp@sc8-pr-shell1 htdocs]$ touch reference_de.html
>   touch: cannot touch `reference_de.html': Permission denied
>
> ad 3) Documentation
> While I am not familiar with lisp I think it would be ok, but not in the
> current form: With the current approach of the program, every new
> language would mean a new program (or some loop over all languages,
> which would be in the same program, would be required). This makes it
> harder to change the program in the future. Some separation between the
> texts and the program would be good. It is not necessary to have xml
> for the texts (in fact I do not like xml too much), I could also imagine
> a format similar to the lisp code, but only taken out of the program.
> Of course all other texts (like Command, Example, Note, the title, ...)
> need to be translated, too.
>
> BTW, when do you plan to release version 1.0?
>
> Thank you and best regards,
> Immo
>
> Am Sun, 10 Dec 2006 15:46:34 -0800
> schrieb "Ian Larsen" <dr...@gm...>:
>
> >  Ok, let me try not to leave anything out:
> >
> > The way you're committing your translation to svn is fine, it seems to
> > be working out well.  You don't have to change anything there.
> >
> > The bug/request tracker is great for individual requests.  What
> > doesn't work so well is when people put multiple requests in one
> > tracker item - then it can't be closed until everything is addressed,
> > which defeats the purpose of the tracker.
> >
> > > Regarding the documentation: it would be good to have the
> > > command documentation separated into some yaml or xml format.
> >
> > The way I generate the documentation is with a Lisp program, which is
> > attached and looks like this:
> >
> > (kbcommand
> >   "Tan"
> >   "tan ( <i>expression</i> )"
> >   "Computes the tangent of <i>expression</i>. <i>Expression</i> must
> > be in radians."
> >   :seealso "Sin, Cos"
> >   :note "The tan function does not produce an exact result.")
> >
> > This generates the single HTML page and all of the individual ones
> > that are included in the zip file.
> >
> > Now, as far as the xml goes, I can easily generate xml with the Lisp
> > file too.   Would you rather that, or would it be easier if I just
> > made the lisp program available so that you could translate that?
> > (gnu CLisp understands special characters via unicode)
> >
> > I really like the idea of having the documentation in subversion, we
> > just need to agree what format will be easiest to work with.
> >
> >
> > > @Ian, regarding the current German online reference: would it
> > > be possibe to give me shell access to the project html files and
> > > write permisson for the German documentation?
> >
> > Sure.  In fact, I think you already have access, you just need to set
> > up an ssh key and you should be able to log in.  That includes all of
> > the developers, too, if you need to change anything.
> >
> > Maybe we should set up a subversion folder for the web site, too.  It
> > might be easier to change if we all had an up-to-date copy.   If
> > you're going to go through the trouble of translating everything, it
> > will probably be easier this way.
> >
> > > From my class I do have some feature requests. Again the question:
> > > shall I use the project request tracker or rather send an e-mail?
> >
> > Let's talk about them over email and add the ones to the tracker that
> > make sense for the 1.0 release.
> >
> > -Ian
> >
> >
> > On 12/10/06, Immo-Gert Birn <imm...@gm...> wrote:
> > > Hello all,
> > >
> > > this is going to be a longer mail, sorry.
> > >
> > > First of all I have to commit to a stupid mistake: I did not
> > > subscribe to the kidbasic-devel mailing list. Thus I did not get
> > > your replies and the "new release" announcement. Anyway, thank you
> > > for welcoming me.
> > >
> > > I did already some svn commits to update the German translation. I
> > > hope this was ok. I am not sure whether I should add a log message
> > > - what do you think?
> > > It is also not clear for me whether I do something wrong when using
> > > lupdate: the ts-files generated always have lines
> > >   ...location filename="../<filename>" ...
> > > Normally I simply delete these lines using an editor before svn
> > > commit in order to keep the diff small. Don't you also get these
> > > lines? Additionally, I do always revert all lupdate changes to
> > > files other than the German translation - I hope this is ok.
> > >
> > > I filed the bug about the "step" in long vertical and horizontal
> > > lines drawn with the LINE command. Ian already resolved this -
> > > thank you. Is it ok to use the bug tracker or do you prefer an
> > > e-mail?
> > >
> > > From my class I do have some feature requests. Again the question:
> > > shall I use the project request tracker or rather send an e-mail?
> > >
> > > Regarding the documentation: it would be good to have the
> > > command documentation separated into some yaml or xml format. This
> > > would allow to generate the online reference and the release
> > > documentation (as included in the windows zip file) for all
> > > languages and ease the translation. In case you agree, I can start
> > > to do this - probably I'll choose yaml for the text format and
> > > write some ruby scripts. But this would mean that the documentation
> > > for new commands is done in the English master file only and then
> > > translated. I would very much like to have the documentation
> > > language files as well as the needed scripts and html templates in
> > > some folder in the svn repository. This would make the maintenance
> > > of these tools transparent, allow bug fixes, and translators could
> > > simply check the svn log and svn diff of the English documentation
> > > in order to catch up with changes. Your ideas and proposals
> > > regarding these topics are very welcome.
> > >
> > > @Ian, regarding the current German online reference: would it
> > > be possibe to give me shell access to the project html files and
> > > write permisson for the German documentation? Then I could simply
> > > update it as I finish some new command, fix bugs or apply small
> > > changes to the file. I do also plan to translate the tutorials and
> > > the "Why basic?" text - I hope this is ok with you.
> > >
> > > Best regards,
> > > Immo
> > >
> > >
>