[Scilab-Dev] Scilab localization

[Sylvestre Ledru]

Thanks for your inputs.
We are going to freeze messages ASAP. Then please answer when you can !

> Good idea and good starting point! some remarks however:
> 
> Data type naming
> -------------------------
>  - for 1x1 array I think it shoud be better to just use the article "a"
> : a real, a polynom, a character string, a boleean, a rational fraction,
> a (8|16|32)-bit integer, an (8|16|32)-bit integer,... rather than the
> term scalar
Updated in the Wiki.
http://wiki.scilab.org/Localization_in_English_-_Standard_messages

> - for matrices squareness is also often tested, there is also test on
> particular properties (upper/lower triangular, diagonal, symmetric,
> hermitian, definite positive,...
I didn't see much of this in the code?!

> - the terms "vector" and "matrix" refer to linear algebra, so for
> character strings it is better to use the term "array".  May be is
> should be a good idea to use either matrix/vector or array depending on
> the fact we are in the context of linear algebra or not
> for exemple it is better to call the output of the root function "column
> array" instead of column vector. Similarily it should be better to
> refer  input/output of sin as array rather than matrix, but the msin
> arguments should be refer a matrices.
Could you update the Wiki ? 
I am not sure on which cell(s) you are refering to.

> - In my opinion it should be better not to see  hypermat's (arrays with
> more than 2 dimensions) as a special case (the way they are coded)  but
> just the case of arrays with more than 2 dimensions adding a column at
> the right of the tabular. It alsobe better to denote them "nD arrays"
> rather than hypermatrices.
Same here

> - The cells (ce) are used to store 2D or nD  arrays where each entry can
> have every type
And ?

> -The structs (st) are used to store datastructure they can have multiple
> fields and can also have dimensions
And ?


> - some examples do not follow the above data type naming( string instead
> of character string
why ?

> - it should be more convenient to refer the argument position by a
> number :
> "%s: Wrong type for input argument number %d: a character string
> expected.\n"
I like the idea. it is quite a big work but we have to do it. Next time, please a have look sooner :/
Laurent is proposing
%s: Wrong type for input argument #%d: xxx expected.\n"

> - for wrong values, I think it is better saying "elements must have ....
> "%s: Input argument number %d must have finite elements.\n"
> "%s: Input argument number %d  must have elements with integer values.\n"
> "%s: Input argument number %d must have non negative integer elements.\n"
> "%s: Input argument number %d : Must have its elements in ]%d %d].\n"
> "%s: Input argument number %d : Must have its elements in [%d %d[.\n"
Why don't you like the other way ?

> - for wrong sizes, I prefer to use the term "length" for the size of a
> character string:
> "%s: Argument number %d  must have a length less than %d\n" 
Why ?

> - for incompatible size (or type) I think the message shoud include the
> numbers of the corresponding input arguments
> "%s: Incompatible arguments %d and %d. They should have the same row
> dimension\n"
> "%s: Incompatible arguments %d and %d. They should have the same number
> of elements\n"
Yep, we do that when it is possible 
> Error message/memory
> 
> There is currently to different error message relative to memory ( the
> scilab stack is not big enough, it is not possible to allocate more memory)
> "%s: Not enough allocatable memory (requested %d bytes).\n"
> "%s: Too small stack  (requested %d bytes, available %d bytes).\n stack
> size may ne increased using the stacksize function"
Yep, we are trying to not mix them. It is easy to see the different
cases in the code.

S