only-en qualiweeks pick-24 added captions

Author: bili123

src/onprem/en/robotmk.asciidoc

@@ -519,13 +519,15 @@ Here in the screenshot, under [.guihint]#Plan Settings# you can see the upload f
 Pay attention to the name at the top under [.guihint]#Properties.#
 This is mandatory, as the robot will later be configured in the scheduler using this name.
 
+.The robot itself is simply transferred as an archive 
 image::robotmk_managed_robots_robot.png[alt="Configuration of a managed robot."]
 
 To use such a [.guihint]#Managed robot#, the [.guihint]#Robotmk scheduler (Windows|Linux)# rule is again used.
 But instead of scheduling the execution of the robot here, simply specify the desired, preconfigured robot under [.guihint]#Sequence of plans#.
 If required, you can still adapt the plan's configuration for the preconfigured robot for this application here.
 In practice, the feature is therefore usually limited to outsourcing the known configuration and having the robot archive files distributed by the agent. 
 
+.The [.guihint]#mybot_managed# managed robot is scheduled using the default plan configuration
 image::robotmk_managed_robots_scheduler.png[alt="Configuration of the scheduler with a managed robot."]
 
 The agent then transfers the specified archives to the desired hosts and stores them in the agent directory under `robomk_output/managed`, where they are then unpacked and finally executed.
@@ -939,6 +941,7 @@ In the [.guihint]#Robotmk Scheduler (Windows|Linux)# rule (or in [.guihint]#Mana
 Please do not confuse this path with the `holotree path`!
 This serves only as a repository for the Hololib catalog ZIPs to be imported.
 
+.The storage location for zipped Hololib catalogs (templates for building environments)
 image::robotmk_rcc_offline_dependency_handling.png[alt="Information on handling a zipped catalog."]
 
 When the scheduler is later started, it will import all Hololib catalog ZIPs and build the spaces from these templates, i.e. the environments that are actually going to be used.
@@ -962,17 +965,20 @@ You can find out how to set up RCCRemote-Docker, handle certificates and import
 
 The configuration on the {CMK} side is now again -- typically -- quite simple: The [.guihint]#Environment dependency handling# option is this time set to [.guihint]#Fetch from RCC remote server# and supplied with the server's address. 
 
+.The RCCRemote Docker can deliver catalogs via the network
 image::robotmk_rcc_offline_dependency_handling_2.png[alt="Specification for handling RCCRemote."]
 
 One final setting is still missing, depending on whether your RCCRemote server uses a self-signed or a CA-signed certificate.
 In both cases, you usually have to set [.guihint]#Robotmk scheduler (Windows|Linux)# the option [.guihint]#RCC profile configuration# to [.guihint]#Custom profile#.
 
 For a self-signed certificate, it is sufficient to leave the [.guihint]#Validate TLS certificates# box unchecked:
 
+.TLS certificates do not necessarily have to be validated.
 image::robotmk_rcc_offline_tls_self.png[alt="Inactive TLS validation for self-signed certificates."] 
 
 If, however, it is a CA-signed certificate, this option must be activated and the certificate from the signing authority must be stored under [.guihint]#Root CA# (in PEM format):
 
+.CA-signed TLS certificates are validated as usual by specifying the root CA
 image::robotmk_rcc_offline_tls_ca.png[alt=”Stored certificate from the CA."]