computational region in grasswxpy.po file

[lucadelu]

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)"

Luca

[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.

Markus

[martinl]

Replying to 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.

[hamish]

Replying to 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.

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

Hamish

[neteler]

Replying to hamish:

Replying to 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).

[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.

Just my 2c,

Markus M

[hamish]

Replying to 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 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?

Hamish

[mmetz]

Replying to hamish:

Replying to 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.

Markus M