5:53 p.m.
Ok, I have just done my first cvs commit (de.po) to see whether from that minute on gretl
will stop
working ;-)
No seriously, before I can translate larger chunks I have some questions, because I very
much
realize that I am a novice at program translation.
1) actually unrelated to translation: could it be that some menu shortcuts are doubly
defined in
English gretl? Like "user's guide" and "check for updates" both
receiving the u-shortcut in the help
window. (I presume lower or uppercase is irrelevant, right?)
2) Speaking about menu shortcuts, what letter to choose for menu shortcuts in the
translations? Is
there a rule, or am I free to choose whatever I like? (Related info: It seems that in the
existing
translation in some cases there is a shortcut in English, but not in the corresponding
German string.)
3) Is it really necessary to "translate" menu separators appearing as strings?
Or could they even be
marked as not requiring translation in the sources?
4) To test out the effect of the changes without building myself, are the changes
automatically
included in the windows snapshot http://ricardo.ecn.wfu.edu/pub/gretl/gretl_install.exe?
At what
interval is the snapshot brought up to date?
5) In the de.po file it says something about project id gretl 1.3.0.1, which sounds
outdated.
Something I can/should change?
Thanks much for your help,
cheers, Sven
4:03 a.m.
On Tue, 10 Jan 2006, Sven Schreiber wrote:
Ok, I have just done my first cvs commit (de.po) to see whether
from that minute on gretl will stop working ;-)
Looks good so far!
1) actually unrelated to translation: could it be that some menu
shortcuts are doubly defined in English gretl? Like "user's guide"
and "check for updates" both receiving the u-shortcut in the help
window. (I presume lower or uppercase is irrelevant, right?)
Quite possible. I'll try checking that.
2) Speaking about menu shortcuts, what letter to choose for menu
shortcuts in the translations? Is there a rule, or am I free to
choose whatever I like?
If there's a rule, I'm not aware of it -- other than, try to choose
the most standard option (used in most other software), if there is
any standard option for the menu item in question.
3) Is it really necessary to "translate" menu separators
appearing
as strings? Or could they even be marked as not requiring
translation in the sources?
Yes, that seems stupid. I'll see if I can fix it.
4) To test out the effect of the changes without building myself,
are the changes automatically included in the windows snapshot
http://ricardo.ecn.wfu.edu/pub/gretl/gretl_install.exe? At what
interval is the snapshot brought up to date?
Yes, .po changes automatically go into the snapshot. As for the
timing of updates, this is somewhat irregular. Basically it's
matter of: Is there something new that is worthwhile, or a
significant bugfix? (If yes, then make a snapshot.) Is there
something experimental going on in CVS which is liable to produce a
broken binary? (If yes, then don't make a snapshot.)
Right now there is experimental stuff going on (we're adding the
facility to define and manipulate matrices), but I don't think any
existing functionality is broken so I'll make a new Windows
snapshot tomorrow, Jan 11.
5) In the de.po file it says something about project id gretl
1.3.0.1, which sounds outdated. Something I can/should change?
Yes, I believe you're free to change that identifier to "1.5.0".
Thanks for your work on this!
Allin Cottrell
6:34 p.m.
On Tue, Jan 10, 2006 at 11:03:58PM -0500, Allin Cottrell wrote:
>1) actually unrelated to translation: could it be that some menu
>shortcuts are doubly defined in English gretl? Like "user's guide"
>and "check for updates" both receiving the u-shortcut in the help
>window. (I presume lower or uppercase is irrelevant, right?)
Quite possible. I'll try checking that.
There is nothing in the .po file system that prevents that. Although suboptimal,
you can assign the same shortcut to different menu items (pressing the relevant
key will cycle through the items).
>2) Speaking about menu shortcuts, what letter to choose for menu
>shortcuts in the translations? Is there a rule, or am I free to
>choose whatever I like?
If there's a rule, I'm not aware of it -- other than, try to choose
the most standard option (used in most other software), if there is
any standard option for the menu item in question.
You can find some useful references in the translation guides from the GNOME or
KDE desktop environments:
http://developer.gnome.org/projects/gtp/style-guides/
http://i18n.kde.org/translation-howto/
Happy translating!
Cri
--
GPG/PGP Key-Id 0x943A5F0E - http://www.linux.it/~cri/cri.asc
Free software, free society - http://www.fsfeurope.org
12:22 a.m.
Allin Cottrell schrieb:
Right now there is experimental stuff going on (we're adding the
facility to define and manipulate matrices), but I don't think any
existing functionality is broken so I'll make a new Windows snapshot
tomorrow, Jan 11.
Using it now, and being pleasantly surprised by the already included
Gini/Lorenz stuff - thanks very much! (btw, maybe the menu entry should
include Lorenz since it automatically produces the Lorenz curve -- for
example "Gini, Lorenz")
Some more questions related to the translation, focusing on the more
fundamental ones:
- Now that I have to think about it I realized that I'm a bit confused
by the menu structure in the main window, especially concerning the
triad data-sample-variable. What are the defining characteristics for
menu entries in each of those menus? For example, it would seem more
natural to look for modification of the "dataset structure" under the
"data" menu instead of "sample". (It could also be I'm
misunderstanding
the scope of commands that modify the dataset structure.) There are also
other cases that I currently find misplaced, but maybe not anymore after
understanding the official point of view.
Thanks,
Sven
1:02 a.m.
On Thu, 12 Jan 2006, Sven Schreiber wrote:
Using it now, and being pleasantly surprised by the already
included Gini/Lorenz stuff - thanks very much! (btw, maybe the
menu entry should include Lorenz since it automatically produces
the Lorenz curve -- for example "Gini, Lorenz")
I'll try to think of a better string for that menu item.
- Now that I have to think about it I realized that I'm a bit
confused by the menu structure in the main window, especially
concerning the triad data-sample-variable. What are the defining
characteristics for menu entries in each of those menus? For
example, it would seem more natural to look for modification of
the "dataset structure" under the "data" menu instead of
"sample".
You have a point. I'm not totally clear on how all the specific
menu items should best be distributed between the Data, Sample and
Variable headings. The layout has basically "just grown" to its
current form, and I'd be glad to hear suggestions for
rationalizing it.
Allin Cottrell
3:05 p.m.
Allin Cottrell schrieb:
You have a point. I'm not totally clear on how all the specific
menu
items should best be distributed between the Data, Sample and Variable
headings. The layout has basically "just grown" to its current form,
and I'd be glad to hear suggestions for rationalizing it.
Ok, here are my suggestions for the "evolution" of the menu structure,
reshuffling some menu entries
between the "data", "sample", "variable" menus to hopefully
make it more intuitive. (Of course,
sometimes it might be the case that I simply haven't understood what the respective
command really
does... In those cases, please correct and enlighten me.)
I) "Data" menu: I interpret that as relating to the loaded dataset as a whole,
so one may think of
renaming that to "Dataset" instead. Given that interpretation, the following
items should be moved
elsewhere:
1. graph specified vars (-> "sample")
2. Multiple scatterplots (-> "sample")
3. everything from summary statistics to differences of variances should also go to
"sample"
II) "Sample" menu: in my view, all commands that act on or modify data in the
current sample range
(as opposed to the entire dataset) should come here. (see what was moved from
"data" in I) Therefore
remove:
1. Dataset structure / compact data /expand data (-> "data(set)")
2. restructure panel / transpose data (also -> "data(set)")
[3. not sure about the missing-value and case marker things, don't know enough about
them)
III) "Variable" menu: interpreted as variants of univariate analsis, so move:
1. find (-> "data(set)")
2. define new variable ( "data(set)")
[3. again not sure about the missing-value issue, why here _and_ in "sample"?)
So what do you guys think? Of course experienced users would have to adapt, but I would
argue the
changes are relatively mild and make more sense in the longer run.
cheers,
sven
11:55 p.m.
On Thu, 12 Jan 2006, Sven Schreiber wrote:
I) "Data" menu: I interpret that as relating to the loaded
dataset as a whole, so one may think of
renaming that to "Dataset" instead. Given that interpretation, the following
items should be moved
elsewhere:
1. graph specified vars (-> "sample")
2. Multiple scatterplots (-> "sample")
3. everything from summary statistics to differences of variances should also go to
"sample"
II) "Sample" menu: in my view, all commands that act on or modify data in the
current sample range
(as opposed to the entire dataset) should come here. (see what was moved from
"data" in I) Therefore
remove:
1. Dataset structure / compact data /expand data (-> "data(set)")
2. restructure panel / transpose data (also -> "data(set)")
[3. not sure about the missing-value and case marker things, don't know enough about
them)
III) "Variable" menu: interpreted as variants of univariate analsis, so move:
1. find (-> "data(set)")
2. define new variable ( "data(set)")
[3. again not sure about the missing-value issue, why here _and_ in "sample"?)
So what do you guys think? Of course experienced users would have to adapt, but I would
argue the
changes are relatively mild and make more sense in the longer run.
Makes sense to me, although the distinction you draw between "data" and
"sample" looks a bit fuzzy to me: following your logic, the whole
variable-generation machine should go under "sample".
And while we're at it, is the model menu to be left untouched? I mean, I
wouldn't mind an organisation like
OLS
-------------
Other least-squares estimators -> IV, Weighted, ...
-------------
Time series
-------------
Qualitative & limited dependent -> Logit, Probit, Tobit
-------------
Count data -> Only Poisson for now
-------------
System -> VARs could go in here
-------------
Other
-------------
Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti
10:17 a.m.
Thanks for your feedback!
jack schrieb:
Makes sense to me, although the distinction you draw between "data" and
"sample" looks a bit fuzzy to me: following your logic, the whole
variable-generation machine should go under "sample".
I'd say that depends on whether the commands perform calculations only for the current
sample range
or for the entire dataset range. I confess that I simply don't know which of these is
true, and I
guess both variants have their virtues.
And while we're at it, is the model menu to be left untouched? I
mean, I
wouldn't mind an organisation like
Surely there's room for further opimization within the menus, which I tend to view as
independent
from rearranging items across menus, however.
OLS
-------------
Other least-squares estimators -> IV, Weighted, ...
-------------
Time series
-------------
Qualitative & limited dependent -> Logit, Probit, Tobit
-------------
Count data -> Only Poisson for now
-------------
System -> VARs could go in here
-------------
Other
-------------
no strong opinion from me about this one, although it's probably better than the
status quo... but
VARs are Time Series as well as Systems, so finding the best categories will sometimes be
difficult.
cheers,
sven
3:19 p.m.
New subject: menu layout (was questions about translation details)
On Thu, 12 Jan 2006, Sven Schreiber wrote:
Ok, here are my suggestions for the "evolution" of the menu
structure, reshuffling some menu entries between the "data",
"sample", "variable" menus to hopefully make it more intuitive.
(Of course, sometimes it might be the case that I simply haven't
understood what the respective command really does... In those
cases, please correct and enlighten me.)
OK, this is useful. You're forcing me to try to articulate the
thinking behind the current layout. Ideally, of course, a set of
GUI menus should be "transparent" to the user without having
to read about its rationale, but here goes:
"Data" menu: Basically contains "things you might want to do with
more than one variable" -- other than constructing a model, which
has its own menu branch. Examples: graphing, summary statistics,
etc. Plus some things pertaining to the data set as a whole --
other than setting the sample range, which again has its own branch.
Examples: edit values, read informative text, if any.
"Sample" menu: The core functionality here is setting the sample
range in various ways. Some other functions have been added here
(e.g. set dataset structure, transpose data), and the location of
these extra items may be debatable.
"Variable" menu: Fairly clear -- things you might want to do with a
single variable.
A few more comments in the light of the above.
I) "Data" menu: I interpret that as relating to the loaded
dataset
as a whole, so one may think of renaming that to "Dataset"
instead.
As above, it's not just the dataset as a whole; it mostly pertains
to subsets (selections) of variables. You suggest the move:
1. graph specified vars (-> "sample")
I'll resist that. The Sample menu is basically about resetting the
sample, not performing operations on subsets of variables.
I can see a case for creating a "Dataset" menu branch, and putting
all (and only) items dealing with the entire dataset (other than
sampling?) in there (that would include some items that are
currently under "Data" and a few that are currently under Sample,
such as transpose).
That leaves a problem with the items that are currently under Data
but that would not fall under the new "Dataset". And I'd really
prefer not to increase the total number of menu branches, if
possible. Hmmm. I'll think about this some more.
Allin Cottrell
10:46 p.m.
New subject: menu layout (was questions about translation details)
Allin Cottrell wrote:
"Data" menu: Basically contains "things you might want
to do with more
than one variable" -- other than constructing a model, which has its own
menu branch. Examples: graphing, summary statistics, etc. Plus some
things pertaining to the data set as a whole -- other than setting the
sample range, which again has its own branch. Examples: edit values,
read informative text, if any.
Ok I understand it better now: for example I realized that the
"data"-commands work with the currently selected sample and never (?)
with the entire dataset. Nevertheless, having things like "sort
variables" and "mahalanobis distances" in the same menu is a bit
difficult to understand.
Therefore I would at least suggest to group the commands together that
are related to dataset-management. (Right now there are some at the top
and some at the bottom.) As a result the "data" menu would have two main
blocks, one for management commands, and one for descriptive statistics
(loosely speaking).
"Sample" menu: The core functionality here is setting the sample range
in various ways. Some other functions have been added here (e.g. set
dataset structure, transpose data), and the location of these extra
items may be debatable.
Yes I would still argue that putting those in the data menu would be
better. After all, that was the starting point of my confusion.
> 1. graph specified vars (-> "sample")
I'll resist that. The Sample menu is basically about resetting the
sample, not performing operations on subsets of variables.
ok, makes sense now that I understand the purpose of the sample menu,
and provided the above changes are made.
I can see a case for creating a "Dataset" menu branch, and putting all
(and only) items dealing with the entire dataset (other than sampling?)
in there (that would include some items that are currently under "Data"
and a few that are currently under Sample, such as transpose).
That leaves a problem with the items that are currently under Data but
that would not fall under the new "Dataset". And I'd really prefer not
to increase the total number of menu branches, if possible. Hmmm. I'll
think about this some more.
I agree that the menu should not grow beyond the 7 branches (+1 help).
That's why I suggested to divide the data menu into two groups. (On the
other hand, compared to the other menus the "session" menu is quite an
outlier with only 4 entries, one of which has a toolbar button, and then
the two save-variants. I could imagine subsuming that entire menu under
the "file"-menu, after all that's were files are opened and saved... but
hey, it's not my intention to turn the gretl menu structure upside down
and irritate all longtime and faithful gretl users! So maybe you
shouldn't follow my suggestions too literally ;-)
Whatever you decide, if there's going to be some cleanup, I'm glad.
cheers,
Sven
6901
days inactive
6906
days old
9 comments
4 participants
participants (4)
-
Allin Cottrell -
Cristian Rigamonti -
jack -
Sven Schreiber