Merge pull request #2797 from smoe/docs_translations_mix_01

presumed smallish corrections for the documentation smoe/docs_translations_mix_01

Author: hansu

docs/README.adoc

@@ -21,7 +21,7 @@ generating translated files using the files in docs/po/.
 
 == Notes on LinuxCNC documentation
 
-The main LinuxCNC makefile can optionally build the documentation and
+The main LinuxCNC Makefile can optionally build the documentation and
 other files in this directory tree. Use "--enable-build-documentation"
 when invoking src/configure, and run "make" from src.
 
@@ -40,11 +40,11 @@ which is available for many systems, see link:https://repology.org/project/qcad/
 Unfortunately, EasyCAD (and AutoCAD) support a number of entities
 that QCAD does not import properly. Including some that were used
 in the LinuxCNC drawings: filled circles, filled arrowheads, non-zero
-width lines, and dashed lines.  Qcad renders filled circles as
+width lines, and dashed lines.  QCAD renders filled circles as
 hollow, it renders all lines the same width, and it renders dashed
 lines as solid, unless you tell it to do otherwise.  All of these
 things make the drawings less attractive, but are somewhat
-acceptable.  However, Qcad doesn't import filled arrowheads at all,
+acceptable.  However, QCAD doesn't import filled arrowheads at all,
 which seriously hurts the drawings.  So EasyCad was used to convert
 the arrowheads to hollow before exporting them.  Hollow arrowheads
 don't look as nice as solid ones, but at least they are visible.
@@ -53,7 +53,7 @@ Once exported, the arrowheads lose their relationship with the line they
 are on, and need to be moved and/or rotated manually if the line is
 moved.  I believe that even if they were imported back into EasyCad, the
 line/arrow connection would remain broken. New lines with arrowheads can
-be created in Qcad with the 'leader' dimension tool.
+be created in QCAD with the 'leader' dimension tool.
 
 Because the original EPS files with filled lines and circles, wide lines,
 and dashed lines look so much nicer, they will remain in Git and should

docs/src/drivers/hal_gpio.adoc

@@ -52,15 +52,15 @@ gpiochip0 - 54 lines:
 ...
 ----
 
-A list of input and/or output pins should be specified as shown in the sample above. (the \ character is used for line continuation in HAL, and is used to improve readability. The pin names are case-sensitive and there must be no spaces in the strings, either beteen the comma-separated pins lists of the "=" signs.
+A list of input and/or output pins should be specified as shown in the sample above. (The \ character is used for line continuation in HAL, and is used to improve readability. The pin names are case-sensitive and there must be no spaces in the strings, either beteen the comma-separated pins lists of the "=" signs.)
 
 Additional modifiers are:
 *invert* (valid for outputs only). Inverts the sense of the physical pin relative to the value in HAL.
 
 *reset* (valid for outputs only). If any pins are allocated to the "reset" list than a HAL parameter *hal_gpio.reset_ns* will be created. This will have no effect unless the *hal_gpio.reset* function is added to a realtime thread. This should be placed after the *hal_gpio.write* function and must be in the same thread. The behaviour of this function is equivalent to the same function in the *hal_parport* driver, and it allows a step pulse every thread cycle. If the *hal_gpio.reset_ns* time is set longer than 1/4 of the period of the thread that it is added to, then the value will be reduced to 1/4 the thread period. There is a lower limit to how long the pulse can be. With 8 pins in the output list the pulse width can not reduce lower than 5000ns on a Pi4, for example.
 
 The following functions are accepted in all versions, but are only effective if a version of libgpiod_dev >= 1.6 is installed.
-They should be used in the same way as the parameters described above, and will alter the electrical paramters of the GPIO pins *if* this is supported by the hardware.
+They should be used in the same way as the parameters described above, and will alter the electrical parameters of the GPIO pins *if* this is supported by the hardware.
 
 *opendrain*
 

docs/src/gcode/g-code.adoc

@@ -1709,8 +1709,8 @@ It is an error if:
 == G71 G72 Lathe roughing cycles(((G71 G72 Lathe roughing cycles)))
 
 [NOTE]
-The G71 and G72 cycles are currently somewhat fragile. See issues #707
-and #1146
+The G71 and G72 cycles are currently somewhat fragile.
+See issues https://github.com/LinuxCNC/linuxcnc/issues/707[#707] and https://github.com/LinuxCNC/linuxcnc/issues/1146[#1146].
 
 [source,{ngc}]
 ----

docs/src/gui/qtdragon.adoc

@@ -829,7 +829,7 @@ Sequence after pressing the probe button: +
 . probe wall twice (rough and fine),
 . move diagonally to the other wall as set by EDGE WIDTH and XY CLEARANCE,
 . probe wall twice,
-. raise probe up by Z CLEARANCE + EXTRA DEPTH 9returns to starting height),
+. raise probe up by Z CLEARANCE + EXTRA DEPTH (returns to starting height),
 . rapid back to starting corner (now calculated using the probed walls),
 . if auto zero button is enabled, set X and Y of the current user system to zero.
 
@@ -898,10 +898,10 @@ The sequence of events (using the default files):
 * Return Z to position defined in the INI's [TOOL_CHANGE] Z
 
 [NOTE]
-The [TOOL_CHANGE] Z position should be high enough so the tool will not hit the tool probe 
+The [TOOL_CHANGE] Z position should be high enough so the tool will not hit the tool probe
 when moving to the [VERSA_TOOLSETTER] X and Y position.
 MAXPROBE distance needs to be high enough for the tool to touch the probe.
- 
+
 === Work Piece Height Probing
 
 .QtDragon_hd - Work piece Height probing
@@ -987,7 +987,7 @@ USE_PROBE = basicprobe
 <<sub:remap:sec:error-handling, Remap Abort Details>>
 
 [NOTE]
-These default entries should work fine in most situations. Some systems may need to use 'linuxcnc/nc_files/examples/' 
+These default entries should work fine in most situations. Some systems may need to use 'linuxcnc/nc_files/examples/'
 instead of 'linuxcnc/nc_files/'. please check that paths are valid. Custom entries pointing to modified file are possible.
 
 [source,{ini}]
@@ -1058,11 +1058,12 @@ Z = -2
 ==== The Python Section
 
 The Python section sets up what files LinuxCNC's Python interpreter looks for, e.g., `toplevel.py` file in the `python` folder in the configuration directory:
-These default entries should work fine in most situations. Some systems may need to use 'linuxcnc/nc_files/examples/' 
-instead of 'linuxcnc/nc_files/'. Custom entries pointing to modified file are possible.
+These default entries should work fine in most situations. Some systems may need to use 'linuxcnc/nc_files/examples/' instead of 'linuxcnc/nc_files/'.
+Custom entries pointing to modified file are possible.
+
 [source,{ini}]
 ----
-# The path start point for all remap searches ie. python's sys.path.append() 
+# The path start point for all remap searches, i.e. Python's sys.path.append()
 PATH_APPEND = ~/linuxcnc/nc_files/remap_lib/python-stdglue/python
 # path to the tremap's 'toplevel file
 TOPLEVEL = ~/linuxcnc/nc_files/remap_lib/python-stdglue/python/toplevel.py
@@ -1175,14 +1176,14 @@ You can also write your own HTML docs with the included SetUp Writer button. +
 There are three sub tabs:
 
 * 'HTML' - any loaded HTML pages are displayed here. The navigation buttons work on this page.
-* 'PDF' - any loaded PDF setup pages are displayed here
-* 'PROPERTIES' - when a program is loaded its gcode properties are displayed here.
+* 'PDF' - any loaded PDF setup pages are displayed here.
+* 'PROPERTIES' - when a program is loaded its G-code properties are displayed here.
 
 There are navigation buttons for HTML page:
 
-* The up arrow returns you to the default HTML page
-* The left arrow moves backward one HTML page
-* The right arrow moves forward one HTML page
+* The up arrow returns you to the default HTML page.
+* The left arrow moves backward one HTML page.
+* The right arrow moves forward one HTML page.
 
 If you wish to include a custom default HTML page, name it 'default_setup.html' and place it in your configuration folder. +
 Custom QtVCP panels can be displayed in this tab by setting the EMBED_TAB_LOCATION option to 'tabWidget_setup'.
@@ -1198,7 +1199,7 @@ The settings tab is used to set running options, probing/touchplate/laser/camera
 
 This tabs will display another stab election of G-code utility programs:
 
-* 'Facing': allows quick face milling of a definable area at angles of 0,45 and 90 degrees
+* 'Facing': allows quick face milling of a definable area at angles of 0,45 and 90 degrees.
 * 'Hole Circle': allows quick setting of a program to drill a bolt circle of definable diameter and number of holes.
 * 'NGCGUI': is a QtVCP version of the popular G-code subroutine builder/selector, see <<sub:qtvcp:widgets:qt-ngcgui,Widgets-NGCGUI>>.
 

docs/src/gui/qtvcp-widgets.adoc

@@ -2722,10 +2722,10 @@ self.w.joypadename.setProperty('false_color','red')
 ----
 
 === 'WebWidget'
-This widget will create a html/pdf viewing page using the QtWebKit or 
-QtWebEngine libraries. The newer QtWebEngine is preferred if both are on the system. +
-If the QtWebEngine library is used with the QtDesigner editor, a placeholder QWidget will show in Qesigner.
-This will be replaced with thw QtWebEngine widget at run time.
+This widget will create a html/pdf viewing page using the QtWebKit or QtWebEngine libraries.
+The newer QtWebEngine is preferred if both are on the system. +
+If the QtWebEngine library is used with the Qt Designer editor, a placeholder QWidget will show in Qesigner.
+This will be replaced with the QtWebEngine widget at run time.
 
 [[sec:qtvcp:widgets:baseclass-mixin]]
 == BaseClass/Mixin Widgets

docs/src/gui/qtvcp.adoc

@@ -277,12 +277,12 @@ Here we show how to add new functions and override existing ones.
 # reference: https://ruivieira.dev/python-monkey-patching-for-readability.html
 import types
 
-# import the handlerfile to get reference to it's libraries.
+# import the handlerfile to get reference to its libraries.
 # use <screenname>_handler
 import qtdragon_handler as hdlr
 
 # This is actually an unbounded function with 'obj' as a parameter.
-# You call this function without the usual preceding 'self.'
+# You call this function without the usual preceding 'self.'.
 # This is because will will not be patching it into the original handler class instance
 # It will only be called from code in this file.
 def test_function(obj):
@@ -329,18 +329,17 @@ self.on_keycall_F11 = types.MethodType(on_keycall_F11, self)
 def new_pin_changed(data):
     print(data)
 
-# special function that gets called before the HAL component is set ready
-# here we used the function to add a bit input pin with a callback
+# Special function that gets called before the HAL component is set ready.
+# Here we used the function to add a bit input pin with a callback.
 def after_override__(self):
     try:
         pin = hdlr.QHAL.newpin("new_pin", hdlr.QHAL.HAL_BIT, hdlr.QHAL.HAL_IN)
         pin.value_changed.connect(new_pin_changed)
     except Exception as e:
         print(e)
 
-# Here we are instance patching the original handler file to add a new
-# function that calls our new function (of the same name)
-# defined in this file
+# Here we are instance patching the original handler file to add a new function
+# that calls our new function (of the same name) defined in this file.
 self.after_override__ = types.MethodType(after_override__, self)
 
 ----
@@ -941,7 +940,7 @@ If QtVCP finds these it will call them, if not it will silently ignore them.
   before the optional HAL file is loaded or HAL component is set ready.
 
 *`processed_key_event__(self,receiver,event,is_pressed,key,code,shift,cntrl):`*::
-  This function is called to facilitate _keyboard jogging_ etc. +
+  This function is called to facilitate _keyboard jogging_, etc. +
   By using the _`keybinding` library_ this can be used to easily add functions bound to keypresses.
 
 *`keypress_event__(self,receiver, event):`*::

docs/src/plasma/qtplasmac.adoc

@@ -3189,8 +3189,8 @@ self.old_method_name = new_method_name
 ----
 
 [NOTE]
-The existing filter code may be observed in the file /bin/qtplasmac_gcode +
-The file sim/qtplasmac/custom_filter.py has example skeleton code for custom filtering
+The existing filter code may be observed in the file /bin/qtplasmac_gcode. +
+The file sim/qtplasmac/custom_filter.py has example skeleton code for custom filtering.
 
 == QtPlasmaC Advanced Topics