#692: computational region in grasswxpy.po file
------------------------------+---------------------------------------------
Reporter: lucadelu | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: default | Version: svn-trunk
Keywords: computational po | Platform: Unspecified
Cpu: Unspecified |
------------------------------+---------------------------------------------
I don't understand what "computational region" means in grasswxpy.po file,
there are a lot of string with "computational region" like "Zoom to
computational region (set with g.region)" or "Set computational region
from selected map(s)"
#692: computational region in grasswxpy.po file
---------------------------+------------------------------------------------
Reporter: lucadelu | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Translations | Version: svn-trunk
Resolution: | Keywords: computational po
Platform: All | Cpu: All
---------------------------+------------------------------------------------
Changes (by neteler):
* platform: Unspecified => All
* component: default => Translations
* cpu: Unspecified => All
Comment:
I don't understand "computational region" either - can we reduce it to
region? Or: I assume that perhaps "current region" was meant? I have a
script to search-replace this in all files once we agree how that should
be called.
#692: computational region in grasswxpy.po file
---------------------------+------------------------------------------------
Reporter: lucadelu | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Translations | Version: svn-trunk
Resolution: | Keywords: computational po
Platform: All | Cpu: All
---------------------------+------------------------------------------------
Comment (by martinl):
Replying to [comment:1 neteler]:
> I don't understand "computational region" either - can we reduce it to
region? Or: I assume that perhaps "current region" was meant? I have a
script to search-replace this in all files once we agree how that should
be called.
AFAIK the initial idea was to distinguish display region (what is
displayed in the map window) and the region where is done raster
computation (e.g. by r.mapcalc). From this POV is "computation region"
quite informative term to me.
#692: computational region in grasswxpy.po file
---------------------------+------------------------------------------------
Reporter: lucadelu | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Translations | Version: svn-trunk
Resolution: | Keywords: computational po
Platform: All | Cpu: All
---------------------------+------------------------------------------------
Comment (by hamish):
Replying to [comment:2 martinl]:
> AFAIK the initial idea was to distinguish display region (what
> is displayed in the map window) and the region where is done
> raster computation (e.g. by r.mapcalc).
Correct.
> From this POV is "computation region" quite informative term to
> me.
As long as we have both a display window and g.region settings for raster
*and* vector etc. (v.in.region, v.in.ascii -r, ps.map, g.region -n, ...),
we will need some vocabulary to distinguish between the two.
#692: computational region in grasswxpy.po file
---------------------------+------------------------------------------------
Reporter: lucadelu | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Translations | Version: svn-trunk
Resolution: | Keywords: computational po
Platform: All | Cpu: All
---------------------------+------------------------------------------------
Comment (by neteler):
Replying to [comment:3 hamish]:
> Replying to [comment:2 martinl]:
> As long as we have both a display window and g.region settings for
raster *and* vector etc. (v.in.region, v.in.ascii -r, ps.map, g.region -n,
...), we will need some vocabulary to distinguish between the two.
>
>
> fwiw I borrowed the term from the SWAN model (GPL).
> http://www.swan.tudelft.nl
> http://vlm089.citg.tudelft.nl/swan/online_doc/swanuse/node24.html
The underlying question is how to translate the currently chosen term
(into other languages like Italian).
#692: computational region in grasswxpy.po file
---------------------------+------------------------------------------------
Reporter: lucadelu | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Translations | Version: svn-trunk
Resolution: | Keywords: computational po
Platform: All | Cpu: All
---------------------------+------------------------------------------------
Comment (by mmetz):
If I remember right, this term in the GUI evolved from "current region" to
"current computational region" (GUI of early grass6 versions) to
"computational region".
g.region and all modules use "current region"; it would help to avoid
confusion if the same term is used throughout for the same thing. Terms
for the different regions (or windows) are defined in the manual of
g.region. So I would vote for either "current region" or "computational
region" but not the one in module man pages and the other in the GUI.
#692: computational region in grasswxpy.po file
---------------------------+------------------------------------------------
Reporter: lucadelu | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Translations | Version: svn-trunk
Resolution: | Keywords: computational po
Platform: All | Cpu: All
---------------------------+------------------------------------------------
Comment (by hamish):
Replying to [comment:5 mmetz]:
> g.region and all modules use "current region"; it would help
> to avoid confusion if the same term is used throughout for
> the same thing. Terms for the different regions (or windows)
> are defined in the manual of g.region. So I would vote for
> either "current region" or "computational region" but not
> the one in module man pages and the other in the GUI.
The dichotomy, and so the need for modifying distinctions, is only present
from the GUI. Adding redundant modifiers into the back-end modules just
adds to the confusion IMO. I am all for improved clarity and consistency,
but am wary that it is very easy to go over the top on such crusades.
(here using the term for the child to describe the parent)
Replying to [comment:5 neteler]:
> The underlying question is how to translate the currently
> chosen term (into other languages like Italian).
Hopefully this discussion better elucidates what the perhaps imperfect
english wording is trying to say?
#692: computational region in grasswxpy.po file
---------------------------+------------------------------------------------
Reporter: lucadelu | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Translations | Version: svn-trunk
Resolution: | Keywords: computational po
Platform: All | Cpu: All
---------------------------+------------------------------------------------
Comment (by mmetz):
Replying to [comment:6 hamish]:
> Replying to [comment:5 mmetz]:
> > g.region and all modules use "current region"; it would help
> > to avoid confusion if the same term is used throughout for
> > the same thing. Terms for the different regions (or windows)
> > are defined in the manual of g.region. So I would vote for
> > either "current region" or "computational region" but not
> > the one in module man pages and the other in the GUI.
>
> The dichotomy, and so the need for modifying distinctions, is only
present from the GUI. Adding redundant modifiers into the back-end modules
just adds to the confusion IMO. I am all for improved clarity and
consistency, but am wary that it is very easy to go over the top on such
crusades.
>
> (here using the term for the child to describe the parent)
>
OK. I guess there will always be some confusion with all the different
regions when displaying a raster map (default region, current
computational region, current display region, the raster's region). In
cases like this ticket, a short citation from the wxGUI manual may clarify
the meaning. It would be nice if the wording is clear without reading too
many manuals (don't say RTFM too often). Unfortunately this needs to be
sorted out for every language separately.