Approval in frontend

backend/ar/basis.json

@@ -286,6 +286,7 @@
         "import_currently_scheduled": "An import is currently scheduled",
         "import_data_has_been_uploaded": "Import data has been uploaded",
         "import_delay_notification": "Your import will be processed in the next some hours. You will get a mail containing the processing log once it's done.",
-        "general": "General"
+        "general": "General",
+        "regular": "Regular"
     }
 }

backend/de/basis.json

@@ -286,6 +286,7 @@
         "import_currently_scheduled": "Ein Import ist derzeit hochgeladen",
         "import_data_has_been_uploaded": "Importdaten wurden heraufgeladen",
         "import_delay_notification": "Ihre Importdaten werden in den n\u00e4chsten Stunden importiert. Sobald der Import durchgef\u00fchrt ist, erhalten Sie ein Log per Mail.",
-        "general": "Allgemein"
+        "general": "Allgemein",
+        "regular": "Regul\u00e4r"
     }
 }

backend/dsb/basis.json

@@ -286,6 +286,7 @@
         "import_currently_scheduled": "An import is currently scheduled",
         "import_data_has_been_uploaded": "Import data has been uploaded",
         "import_delay_notification": "Your import will be processed in the next some hours. You will get a mail containing the processing log once it's done.",
-        "general": "General"
+        "general": "General",
+        "regular": "Regular"
     }
 }

backend/en/basis.json

@@ -286,6 +286,7 @@
         "import_currently_scheduled": "An import is currently scheduled",
         "import_data_has_been_uploaded": "Import data has been uploaded",
         "import_delay_notification": "Your import will be processed in the next some hours. You will get a mail containing the processing log once it's done.",
-        "general": "General"
+        "general": "General",
+        "regular": "Regular"
     }
 }

backend/es/basis.json

@@ -286,6 +286,7 @@
         "import_currently_scheduled": "An import is currently scheduled",
         "import_data_has_been_uploaded": "Import data has been uploaded",
         "import_delay_notification": "Your import will be processed in the next some hours. You will get a mail containing the processing log once it's done.",
-        "general": "General"
+        "general": "General",
+        "regular": "Regular"
     }
 }

backend/fr/basis.json

@@ -286,6 +286,7 @@
         "import_currently_scheduled": "An import is currently scheduled",
         "import_data_has_been_uploaded": "Import data has been uploaded",
         "import_delay_notification": "Your import will be processed in the next some hours. You will get a mail containing the processing log once it's done.",
-        "general": "General"
+        "general": "General",
+        "regular": "Regular"
     }
 }

backend/hsb/basis.json

@@ -286,6 +286,7 @@
         "import_currently_scheduled": "An import is currently scheduled",
         "import_data_has_been_uploaded": "Import data has been uploaded",
         "import_delay_notification": "Your import will be processed in the next some hours. You will get a mail containing the processing log once it's done.",
-        "general": "General"
+        "general": "General",
+        "regular": "Regular"
     }
 }

backend/hu/basis.json

@@ -286,6 +286,7 @@
         "import_currently_scheduled": "An import is currently scheduled",
         "import_data_has_been_uploaded": "Import data has been uploaded",
         "import_delay_notification": "Your import will be processed in the next some hours. You will get a mail containing the processing log once it's done.",
-        "general": "General"
+        "general": "General",
+        "regular": "Regular"
     }
 }

backend/id/basis.json

@@ -286,6 +286,7 @@
         "import_currently_scheduled": "An import is currently scheduled",
         "import_data_has_been_uploaded": "Import data has been uploaded",
         "import_delay_notification": "Your import will be processed in the next some hours. You will get a mail containing the processing log once it's done.",
-        "general": "General"
+        "general": "General",
+        "regular": "Regular"
     }
 }

backend/it/basis.json

@@ -286,6 +286,7 @@
         "import_currently_scheduled": "An import is currently scheduled",
         "import_data_has_been_uploaded": "Import data has been uploaded",
         "import_delay_notification": "Your import will be processed in the next some hours. You will get a mail containing the processing log once it's done.",
-        "general": "General"
+        "general": "General",
+        "regular": "Regular"
     }
 }

backend/iw/basis.json

@@ -286,6 +286,7 @@
         "import_currently_scheduled": "An import is currently scheduled",
         "import_data_has_been_uploaded": "Import data has been uploaded",
         "import_delay_notification": "Your import will be processed in the next some hours. You will get a mail containing the processing log once it's done.",
-        "general": "General"
+        "general": "General",
+        "regular": "Regular"
     }
 }

backend/nl/basis.json

@@ -286,6 +286,7 @@
         "import_currently_scheduled": "An import is currently scheduled",
         "import_data_has_been_uploaded": "Import data has been uploaded",
         "import_delay_notification": "Your import will be processed in the next some hours. You will get a mail containing the processing log once it's done.",
-        "general": "General"
+        "general": "General",
+        "regular": "Regular"
     }
 }

backend/pl/basis.json

@@ -286,6 +286,7 @@
         "import_currently_scheduled": "An import is currently scheduled",
         "import_data_has_been_uploaded": "Import data has been uploaded",
         "import_delay_notification": "Your import will be processed in the next some hours. You will get a mail containing the processing log once it's done.",
-        "general": "General"
+        "general": "General",
+        "regular": "Regular"
     }
 }

backend/pt/basis.json

@@ -286,6 +286,7 @@
         "import_currently_scheduled": "An import is currently scheduled",
         "import_data_has_been_uploaded": "Import data has been uploaded",
         "import_delay_notification": "Your import will be processed in the next some hours. You will get a mail containing the processing log once it's done.",
-        "general": "General"
+        "general": "General",
+        "regular": "Regular"
     }
 }

backend/ru/basis.json

@@ -286,6 +286,7 @@
         "import_currently_scheduled": "\u041f\u043b\u0430\u043d\u0438\u0440\u0443\u0435\u0442\u0441\u044f \u0438\u043c\u043f\u043e\u0440\u0442",
         "import_data_has_been_uploaded": "\u0414\u0430\u043d\u043d\u044b\u0435 \u0438\u043c\u043f\u043e\u0440\u0442\u0430 \u0437\u0430\u0433\u0440\u0443\u0436\u0435\u043d\u044b",
         "import_delay_notification": "\u0412\u0430\u0448 \u0438\u043c\u043f\u043e\u0440\u0442 \u0431\u0443\u0434\u0435\u0442 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u0430\u043d \u0432 \u0431\u043b\u0438\u0436\u0430\u0439\u0448\u0438\u0435 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0447\u0430\u0441\u043e\u0432. \u041f\u043e \u043e\u043a\u043e\u043d\u0447\u0430\u043d\u0438\u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0432\u044b \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u0435 \u043f\u0438\u0441\u044c\u043c\u043e \u0441 \u0436\u0443\u0440\u043d\u0430\u043b\u043e\u043c \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438.",
-        "general": "\u041e\u0431\u0449\u0435\u0435"
+        "general": "\u041e\u0431\u0449\u0435\u0435",
+        "regular": "Regular"
     }
 }

backend/tl/basis.json

@@ -286,6 +286,7 @@
         "import_currently_scheduled": "An import is currently scheduled",
         "import_data_has_been_uploaded": "Import data has been uploaded",
         "import_delay_notification": "Your import will be processed in the next some hours. You will get a mail containing the processing log once it's done.",
-        "general": "General"
+        "general": "General",
+        "regular": "Regular"
     }
 }

backend/tr/basis.json

@@ -286,6 +286,7 @@
         "import_currently_scheduled": "An import is currently scheduled",
         "import_data_has_been_uploaded": "Import data has been uploaded",
         "import_delay_notification": "Your import will be processed in the next some hours. You will get a mail containing the processing log once it's done.",
-        "general": "General"
+        "general": "General",
+        "regular": "Regular"
     }
 }

backend/uk/acquisitions.json

@@ -30,9 +30,9 @@
         "all_acquisitions": "\u0412\u0441\u0456 \u043f\u0440\u0438\u0434\u0431\u0430\u043d\u043d\u044f",
         "base_data": "\u041e\u0441\u043d\u043e\u0432\u043d\u0430 \u0456\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0456\u044f \u043f\u0440\u043e \u043f\u0440\u0438\u0434\u0431\u0430\u043d\u043d\u044f",
         "aquisitions_edit": "\u0420\u0435\u0434\u0430\u0433\u0443\u0432\u0430\u0442\u0438 \u043e\u0442\u0440\u0438\u043c\u0430\u043d\u043d\u044f",
-        "acquisition_place": "Place of acquisition",
+        "acquisition_place": "\u041c\u0456\u0441\u0446\u0435 \u043f\u0440\u0438\u0434\u0431\u0430\u043d\u043d\u044f",
-        "acquisition_place_explica": "The place the objects were acquired.",
+        "acquisition_place_explica": "\u041c\u0456\u0441\u0446\u0435, \u0434\u0435 \u0431\u0443\u043b\u0438 \u043f\u0440\u0438\u0434\u0431\u0430\u043d\u0456 \u043e\u0431'\u0454\u043a\u0442\u0438.",
-        "done_by_controlled": "Done by (contact)",
+        "done_by_controlled": "\u0412\u0438\u043a\u043e\u043d\u0430\u043d\u043e (\u043a\u043e\u043d\u0442\u0430\u043a\u0442\u043d\u0430 \u043e\u0441\u043e\u0431\u0430)",
-        "done_by_controlled_explica": "Using this field, the museum worker who acquired the object for the museum can be linked with a controlled entry in the address book."
+        "done_by_controlled_explica": "\u0412\u0438\u043a\u043e\u0440\u0438\u0441\u0442\u043e\u0432\u0443\u044e\u0447\u0438 \u0446\u0435 \u043f\u043e\u043b\u0435, \u043c\u0443\u0437\u0435\u0439\u043d\u0438\u0439 \u043f\u0440\u0430\u0446\u0456\u0432\u043d\u0438\u043a, \u044f\u043a\u0438\u0439 \u043f\u0440\u0438\u0434\u0431\u0430\u0432 \u043e\u0431'\u0454\u043a\u0442 \u0434\u043b\u044f \u043c\u0443\u0437\u0435\u044e, \u043c\u043e\u0436\u0435 \u0431\u0443\u0442\u0438 \u043f\u043e\u0432'\u044f\u0437\u0430\u043d\u0438\u0439 \u0437 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u043e\u0432\u0430\u043d\u0438\u043c \u0437\u0430\u043f\u0438\u0441\u043e\u043c \u0432 \u0430\u0434\u0440\u0435\u0441\u043d\u0456\u0439 \u043a\u043d\u0438\u0437\u0456."
     }
 }

backend/uk/basis.json

@@ -286,6 +286,7 @@
         "import_currently_scheduled": "\u041f\u043b\u0430\u043d\u0443\u0454\u0442\u044c\u0441\u044f \u0456\u043c\u043f\u043e\u0440\u0442",
         "import_data_has_been_uploaded": "\u0414\u0430\u043d\u0456 \u0456\u043c\u043f\u043e\u0440\u0442\u0443 \u0437\u0430\u0432\u0430\u043d\u0442\u0430\u0436\u0435\u043d\u0456",
         "import_delay_notification": "\u0412\u0430\u0448 \u0456\u043c\u043f\u043e\u0440\u0442 \u0431\u0443\u0434\u0435 \u043e\u0431\u0440\u043e\u0431\u043b\u0435\u043d\u043e \u0432 \u043d\u0430\u0439\u0431\u043b\u0438\u0436\u0447\u0456 \u043a\u0456\u043b\u044c\u043a\u0430 \u0433\u043e\u0434\u0438\u043d. \u041f\u0456\u0441\u043b\u044f \u0437\u0430\u043a\u0456\u043d\u0447\u0435\u043d\u043d\u044f \u043e\u0431\u0440\u043e\u0431\u043a\u0438 \u0432\u0438 \u043e\u0442\u0440\u0438\u043c\u0430\u0454\u0442\u0435 \u043b\u0438\u0441\u0442 \u0456\u0437 \u0436\u0443\u0440\u043d\u0430\u043b\u043e\u043c \u043e\u0431\u0440\u043e\u0431\u043a\u0438.",
-        "general": "\u0417\u0430\u0433\u0430\u043b\u044c\u043d\u0435"
+        "general": "\u0417\u0430\u0433\u0430\u043b\u044c\u043d\u0435",
+        "regular": "\u0417\u0432\u0438\u0447\u0430\u0439\u043d\u0438\u0439"
     }
 }

backend/uk/quality.json

@@ -69,12 +69,12 @@
         "open_access_licence_used": "\u0412\u0438\u043a\u043e\u0440\u0438\u0441\u0442\u043e\u0432\u0443\u0454\u0442\u044c\u0441\u044f \u043b\u0456\u0446\u0435\u043d\u0437\u0456\u044f \u0432\u0456\u0434\u043a\u0440\u0438\u0442\u043e\u0433\u043e \u0434\u043e\u0441\u0442\u0443\u043f\u0443",
         "restrictive_licence_used": "\u0412\u0438\u043a\u043e\u0440\u0438\u0441\u0442\u043e\u0432\u0443\u0454\u0442\u044c\u0441\u044f \u043e\u0431\u043c\u0435\u0436\u0443\u0432\u0430\u043b\u044c\u043d\u0430 \u043b\u0456\u0446\u0435\u043d\u0437\u0456\u044f",
         "one_image": "\u0414\u043b\u044f \u043e\u0431'\u0454\u043a\u0442\u0430 \u0431\u0443\u043b\u043e \u0437\u0430\u0432\u0430\u043d\u0442\u0430\u0436\u0435\u043d\u043e \u043e\u0434\u043d\u0435 \u0437\u043e\u0431\u0440\u0430\u0436\u0435\u043d\u043d\u044f",
-        "legal_check_reason_creator_dead_for_years": "The last recorded creator of the object has been dead for [placeholder_copyright_expiry] or more years.",
+        "legal_check_reason_creator_dead_for_years": "\u041e\u0441\u0442\u0430\u043d\u043d\u0456\u0439 \u0437\u0430\u0440\u0435\u0454\u0441\u0442\u0440\u043e\u0432\u0430\u043d\u0438\u0439 \u0442\u0432\u043e\u0440\u0435\u0446\u044c \u043e\u0431'\u0454\u043a\u0442\u0430 \u043f\u043e\u043c\u0435\u0440 [placeholder_copyright_expiry] \u0430\u0431\u043e \u0431\u0456\u043b\u044c\u0448\u0435 \u0440\u043e\u043a\u0456\u0432 \u0442\u043e\u043c\u0443.",
-        "legal_check_reason_creator_recently_or_not_dead": "The last recorded creator of the object is still alive or has died in the last [placeholder_copyright_expiry] years.",
+        "legal_check_reason_creator_recently_or_not_dead": "\u041e\u0441\u0442\u0430\u043d\u043d\u0456\u0439 \u0437\u0430\u0440\u0435\u0454\u0441\u0442\u0440\u043e\u0432\u0430\u043d\u0438\u0439 \u0442\u0432\u043e\u0440\u0435\u0446\u044c \u043e\u0431'\u0454\u043a\u0442\u0430 \u0432\u0441\u0435 \u0449\u0435 \u0436\u0438\u0432\u0438\u0439 \u0430\u0431\u043e \u043f\u043e\u043c\u0435\u0440 \u043f\u0440\u043e\u0442\u044f\u0433\u043e\u043c \u043e\u0441\u0442\u0430\u043d\u043d\u0456\u0445 [placeholder_copyright_expiry] \u0440\u043e\u043a\u0456\u0432.",
-        "legal_check_msg_type_expect_public_domain": "The object and its (documenting) images \/ representations are likely in the public domain (license status: Public Domain Mark).",
+        "legal_check_msg_type_expect_public_domain": "\u041e\u0431'\u0454\u043a\u0442 \u0442\u0430 \u0439\u043e\u0433\u043e (\u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u0430\u043b\u044c\u043d\u0456) \u0437\u043e\u0431\u0440\u0430\u0436\u0435\u043d\u043d\u044f\/\u0440\u0435\u043f\u0440\u0435\u0437\u0435\u043d\u0442\u0430\u0446\u0456\u0457, \u0439\u043c\u043e\u0432\u0456\u0440\u043d\u043e, \u0454 \u0441\u0443\u0441\u043f\u0456\u043b\u044c\u043d\u0438\u043c \u043d\u0430\u0434\u0431\u0430\u043d\u043d\u044f\u043c (\u043b\u0456\u0446\u0435\u043d\u0437\u0456\u0439\u043d\u0438\u0439 \u0441\u0442\u0430\u0442\u0443\u0441: \u0417\u043d\u0430\u043a \u0441\u0443\u0441\u043f\u0456\u043b\u044c\u043d\u043e\u0433\u043e \u043d\u0430\u0434\u0431\u0430\u043d\u043d\u044f).",
-        "legal_check_msg_type_expect_restricted_legal_status": "The object and images \/ representations of it are likely under restricted access.",
+        "legal_check_msg_type_expect_restricted_legal_status": "\u041e\u0431'\u0454\u043a\u0442 \u0442\u0430 \u0439\u043e\u0433\u043e \u0437\u043e\u0431\u0440\u0430\u0436\u0435\u043d\u043d\u044f\/\u0440\u0435\u043f\u0440\u0435\u0437\u0435\u043d\u0442\u0430\u0446\u0456\u0457, \u0439\u043c\u043e\u0432\u0456\u0440\u043d\u043e, \u043f\u0435\u0440\u0435\u0431\u0443\u0432\u0430\u044e\u0442\u044c \u043f\u0456\u0434 \u043e\u0431\u043c\u0435\u0436\u0435\u043d\u0438\u043c \u0434\u043e\u0441\u0442\u0443\u043f\u043e\u043c.",
-        "current_license": "Current license status",
+        "current_license": "\u041f\u043e\u0442\u043e\u0447\u043d\u0438\u0439 \u0441\u0442\u0430\u043d \u043b\u0456\u0446\u0435\u043d\u0437\u0456\u0457",
-        "creator_represented_by_copyright_collective": "The creator or somebody of the same name is represented by a copyright collective",
+        "creator_represented_by_copyright_collective": "\u0410\u0432\u0442\u043e\u0440 \u0430\u0431\u043e \u043e\u0441\u043e\u0431\u0430 \u0437 \u0442\u0430\u043a\u0438\u043c \u0441\u0430\u043c\u0438\u043c \u0456\u043c'\u044f\u043c \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u0435\u043d\u0430 \u0430\u0432\u0442\u043e\u0440\u0441\u044c\u043a\u0438\u043c \u043a\u043e\u043b\u0435\u043a\u0442\u0438\u0432\u043e\u043c",
-        "plausibility": "Plausibility"
+        "plausibility": "\u041f\u0440\u0430\u0432\u0434\u043e\u043f\u043e\u0434\u0456\u0431\u043d\u0456\u0441\u0442\u044c"
     }
 }

backend/uk/user.json

@@ -152,7 +152,7 @@
         "register_hardware_security_tokens": "\u0417\u0430\u0440\u0435\u0454\u0441\u0442\u0440\u043e\u0432\u0430\u043d\u0456 \u0430\u043f\u0430\u0440\u0430\u0442\u043d\u0456 \u043c\u0430\u0440\u043a\u0435\u0440\u0438 \u0431\u0435\u0437\u043f\u0435\u043a\u0438",
         "enter_verification_code": "\u0412\u0432\u0435\u0434\u0456\u0442\u044c \u043a\u043e\u0434 \u043f\u0456\u0434\u0442\u0432\u0435\u0440\u0434\u0436\u0435\u043d\u043d\u044f",
         "defaults_new_object_page": "\u0417\u0430 \u0437\u0430\u043c\u043e\u0432\u0447\u0443\u0432\u0430\u043d\u043d\u044f\u043c (\u043d\u043e\u0432\u0430 \u0441\u0442\u043e\u0440\u0456\u043d\u043a\u0430 \u043e\u0431'\u0454\u043a\u0442\u0430)",
-        "work_title": "Work title",
+        "work_title": "\u041f\u043e\u0441\u0430\u0434\u0430",
-        "work_title_explica": "Your title at work."
+        "work_title_explica": "\u0412\u0430\u0448\u0430 \u043f\u043e\u0441\u0430\u0434\u0430"
     }
 }

backend/zh/basis.json

@@ -286,6 +286,7 @@
         "import_currently_scheduled": "An import is currently scheduled",
         "import_data_has_been_uploaded": "Import data has been uploaded",
         "import_delay_notification": "Your import will be processed in the next some hours. You will get a mail containing the processing log once it's done.",
-        "general": "General"
+        "general": "General",
+        "regular": "Regular"
     }
 }

frontend/ar/basis.json

@@ -79,6 +79,10 @@
         "color": "Color",
         "tag": "Tag",
         "general": "General",
-        "has": "Has"
+        "has": "Has",
+        "last_updated_at": "Last updated at",
+        "greater_than": "Greater than",
+        "lower_than": "Lower than\r\n",
+        "empty": "Empty"
     }
 }

frontend/de/basis.json

@@ -79,6 +79,10 @@
         "color": "Farbe",
         "tag": "Schlagwort",
         "general": "Allgemein",
-        "has": "Hat"
+        "has": "Hat",
+        "last_updated_at": "Zuletzt bearbeitet am",
+        "greater_than": "Gr\u00f6\u00dfer als",
+        "lower_than": "Kleiner als",
+        "empty": "Leer"
     }
 }

frontend/dsb/basis.json

@@ -79,6 +79,10 @@
         "color": "Color",
         "tag": "Tag",
         "general": "General",
-        "has": "Has"
+        "has": "Has",
+        "last_updated_at": "Last updated at",
+        "greater_than": "Greater than",
+        "lower_than": "Lower than\r\n",
+        "empty": "Empty"
     }
 }

frontend/en/basis.json

@@ -79,6 +79,10 @@
         "color": "Color",
         "tag": "Tag",
         "general": "General",
-        "has": "Has"
+        "has": "Has",
+        "last_updated_at": "Last updated at",
+        "greater_than": "Greater than",
+        "lower_than": "Lower than\r\n",
+        "empty": "Empty"
     }
 }

frontend/es/basis.json

@@ -79,6 +79,10 @@
         "color": "Color",
         "tag": "Tag",
         "general": "General",
-        "has": "Has"
+        "has": "Has",
+        "last_updated_at": "Last updated at",
+        "greater_than": "Greater than",
+        "lower_than": "Lower than\r\n",
+        "empty": "Empty"
     }
 }

frontend/fr/basis.json

@@ -79,6 +79,10 @@
         "color": "Color",
         "tag": "Tag",
         "general": "General",
-        "has": "Has"
+        "has": "Has",
+        "last_updated_at": "Last updated at",
+        "greater_than": "Greater than",
+        "lower_than": "Lower than\r\n",
+        "empty": "Empty"
     }
 }

frontend/hsb/basis.json

@@ -79,6 +79,10 @@
         "color": "Color",
         "tag": "Tag",
         "general": "General",
-        "has": "Has"
+        "has": "Has",
+        "last_updated_at": "Last updated at",
+        "greater_than": "Greater than",
+        "lower_than": "Lower than\r\n",
+        "empty": "Empty"
     }
 }

frontend/hu/basis.json

@@ -79,6 +79,10 @@
         "color": "Sz\u00edn",
         "tag": "Kulcszsz\u00f3",
         "general": "General",
-        "has": "Has"
+        "has": "Has",
+        "last_updated_at": "Last updated at",
+        "greater_than": "Greater than",
+        "lower_than": "Lower than\r\n",
+        "empty": "Empty"
     }
 }

frontend/id/basis.json

@@ -79,6 +79,10 @@
         "color": "Color",
         "tag": "Tag",
         "general": "General",
-        "has": "Has"
+        "has": "Has",
+        "last_updated_at": "Last updated at",
+        "greater_than": "Greater than",
+        "lower_than": "Lower than\r\n",
+        "empty": "Empty"
     }
 }

frontend/it/basis.json

@@ -79,6 +79,10 @@
         "color": "Color",
         "tag": "Tag",
         "general": "General",
-        "has": "Has"
+        "has": "Has",
+        "last_updated_at": "Last updated at",
+        "greater_than": "Greater than",
+        "lower_than": "Lower than\r\n",
+        "empty": "Empty"
     }
 }

frontend/iw/basis.json

@@ -79,6 +79,10 @@
         "color": "Color",
         "tag": "Tag",
         "general": "General",
-        "has": "Has"
+        "has": "Has",
+        "last_updated_at": "Last updated at",
+        "greater_than": "Greater than",
+        "lower_than": "Lower than\r\n",
+        "empty": "Empty"
     }
 }

frontend/nl/basis.json

@@ -79,6 +79,10 @@
         "color": "Color",
         "tag": "Tag",
         "general": "General",
-        "has": "Has"
+        "has": "Has",
+        "last_updated_at": "Last updated at",
+        "greater_than": "Greater than",
+        "lower_than": "Lower than\r\n",
+        "empty": "Empty"
     }
 }

frontend/pl/basis.json

@@ -79,6 +79,10 @@
         "color": "Color",
         "tag": "Tag",
         "general": "General",
-        "has": "Has"
+        "has": "Has",
+        "last_updated_at": "Last updated at",
+        "greater_than": "Greater than",
+        "lower_than": "Lower than\r\n",
+        "empty": "Empty"
     }
 }

frontend/pt/basis.json

@@ -79,6 +79,10 @@
         "color": "Color",
         "tag": "Tag",
         "general": "General",
-        "has": "Has"
+        "has": "Has",
+        "last_updated_at": "Last updated at",
+        "greater_than": "Greater than",
+        "lower_than": "Lower than\r\n",
+        "empty": "Empty"
     }
 }

frontend/qu/basis.json

@@ -79,6 +79,10 @@
         "color": "Color",
         "tag": "Tag",
         "general": "General",
-        "has": "Has"
+        "has": "Has",
+        "last_updated_at": "Last updated at",
+        "greater_than": "Greater than",
+        "lower_than": "Lower than\r\n",
+        "empty": "Empty"
     }
 }

frontend/ru/basis.json

@@ -79,6 +79,10 @@
         "color": "\u0426\u0432\u0435\u0442",
         "tag": "\u0422\u0435\u0433",
         "general": "General",
-        "has": "Has"
+        "has": "Has",
+        "last_updated_at": "Last updated at",
+        "greater_than": "Greater than",
+        "lower_than": "Lower than\r\n",
+        "empty": "Empty"
     }
 }

frontend/tl/basis.json

@@ -79,6 +79,10 @@
         "color": "Color",
         "tag": "Tag",
         "general": "General",
-        "has": "Has"
+        "has": "Has",
+        "last_updated_at": "Last updated at",
+        "greater_than": "Greater than",
+        "lower_than": "Lower than\r\n",
+        "empty": "Empty"
     }
 }

frontend/tr/basis.json

@@ -79,6 +79,10 @@
         "color": "Color",
         "tag": "Tag",
         "general": "General",
-        "has": "Has"
+        "has": "Has",
+        "last_updated_at": "Last updated at",
+        "greater_than": "Greater than",
+        "lower_than": "Lower than\r\n",
+        "empty": "Empty"
     }
 }

frontend/uk/basis.json

@@ -79,6 +79,10 @@
         "color": "\u041a\u043e\u043b\u0456\u0440",
         "tag": "\u0422\u0435\u0433",
         "general": "\u0417\u0430\u0433\u0430\u043b\u044c\u043d\u0435",
-        "has": "Has"
+        "has": "\u041c\u0430\u0454",
+        "last_updated_at": "\u041e\u0441\u0442\u0430\u043d\u043d\u0454 \u043e\u043d\u043e\u0432\u043b\u0435\u043d\u043d\u044f \u043e",
+        "greater_than": "\u0411\u0456\u043b\u044c\u0448\u0435, \u043d\u0456\u0436",
+        "lower_than": "\u041d\u0438\u0436\u0447\u0435, \u043d\u0456\u0436",
+        "empty": "\u041f\u043e\u0440\u043e\u0436\u043d\u044c\u043e"
     }
 }

frontend/uk/images.json

@@ -18,6 +18,6 @@
         "image_overview": "\u041e\u0433\u043b\u044f\u0434 \u0437\u043e\u0431\u0440\u0430\u0436\u0435\u043d\u044c",
         "manipulate_image": "\u0420\u0435\u0434\u0430\u0433\u0443\u0432\u0430\u043d\u043d\u044f \u0437\u043e\u0431\u0440\u0430\u0436\u0435\u043d\u044c",
         "lens_function": "\u041e\u0431'\u0454\u043a\u0442\u0438\u0432 \/ \u0424\u0443\u043d\u043a\u0446\u0456\u044f \u0430\u043d\u043e\u0442\u0430\u0446\u0456\u0457",
-        "image_annotations": "Image annotations"
+        "image_annotations": "\u0410\u043d\u043e\u0442\u0430\u0446\u0456\u0457 \u0434\u043e \u0437\u043e\u0431\u0440\u0430\u0436\u0435\u043d\u044c"
     }
 }

quality-web/de/quality_web.json

@@ -3,7 +3,7 @@
         "puqi": "Publikations-Qualit\u00e4ts-Index (PuQI)",
         "plausi": "Plausibilit\u00e4ts-Check",
         "plausi_legal": "Plausibilit\u00e4ts-Check f\u00fcr Rechteangaben von Objektabbildungen",
-        "puqi_explica": "Der Publikations-Qualit\u00e4ts-Index (PuQI) misst die Vollst\u00e4ndigkeit und The publication quality index measures the completeness and suitability of an object record's publishable information. For example, feedback is given on the availability of an object title and a tags. Objects' descriptions are checked for their length; and linked images' license status is evaluated. Based on these evaluations, a quantitative score is provided to be able to roughly measure the completeness and quality of an object record for publication.",
+        "puqi_explica": "Der Publikations-Qualit\u00e4ts-Index (PuQI) misst die Vollst\u00e4ndigkeit und Eignung ver\u00f6ffentlichbarer Informationen eines Objektdatensatzes. Zum Beispiel werden das Vorhandensein eines Objekttitels und von Schlagworten gepr\u00fcft. Die Objektbeschreibungen werden auf ihre L\u00e4nge gepr\u00fcft, und auch der Lizenzstatus der verlinkten Bilder wird evaluiert. Auf der Grundlage dieser Bewertungen wird eine  quantitative Einsch\u00e4tzung ermittelt, um die Vollst\u00e4ndigkeit und Qualit\u00e4t eines Objektdatensatzes f\u00fcr die Ver\u00f6ffentlichung grob zu messen.",
         "plausi_explica": "Im Rahmen dieses Checks werden die mit einem Objekt verkn\u00fcpften Ereignisse (Herstellung, Benutzung, etc.) auf ihre logische Koh\u00e4renz gepr\u00fcft. Hierzu werden die angegebenen Lebensdaten und Zeiten genutzt. Zum Beispiel kann ein Fahrrad, das 1950 hergestellt wurde, nicht 1870 genutzt worden sein. Genauso ist es unwahrscheinlich, dass eine 1920 aufgenommene Fotografie Ice-T (geboren 1958) zeigt.",
         "plausi_explica_2": "Wurde eine solche logische Inkonsistenz zwischen den verschiedenen Ereignissen der Objektgeschichte gefunden, wird eine Warnung zur\u00fcckgegeben.",
         "plausi_legal_explica": "Dieser Check versucht offensichtliche Probleme bei den Rechte- und Lizenzangaben von Objektabbildungen (etwa Objektfotos) zu identifizieren. Hierzu werden die Lebensdaten der verkn\u00fcpften Schaffenden ausgewertet - entweder wie mitgegeben oder auf Basis von ggfs. mitgelieferten Bez\u00fcgen zu kontrollierten Vokabularen und Normdatenrepositorien wie zur Library of Congress, Wikidata oder  der Gemeinsamen Normdatei der Deutschen Nationalbibliothek:",
@@ -24,7 +24,7 @@
         "select_import_format": "Ein Import-Format ausw\u00e4hlen",
         "upload_a_file": "Eine Datei hochladen",
         "select_file_for_upload": "Datei zum Hochladen ausw\u00e4hlen",
-        "alt_paste_text": "Oder einen Objekt-Datensatz als Text einf\u00fcgen",
+        "alt_paste_text": "Einen Objekt-Datensatz als Text einf\u00fcgen",
         "text": "Text",
         "submit": "Abschicken",
         "news": "Neuigkeiten",
@@ -45,6 +45,18 @@
         "faq_q_birth_death_dates_via_vocabs": "Lebensdaten sind in meinen Objektmetadaten nicht verzeichnet, aber es liegen Normdatenverkn\u00fcpfungen vor. Funktionieren die Checks trotzdem?",
         "faq_a_birth_death_dates_via_vocabs": "Ja. Beim Auslesen der Daten mit bestehenden Normdatenbez\u00fcgen werden zus\u00e4tzliche Informationen zu den Akteuren - wie etwa Lebensdaten - aus den kontrollierten Vokabularen von museum-digital bezogen, so es dort bereits einen Datensatz f\u00fcr denselben Akteur gibt.",
         "outlook_text": "museum-digital:qa bietet eine Plattform, um Museumsdaten aus verschiedensten Quellen einfach ansprechen und weiterverarbeiten zu k\u00f6nnen - spezifisch, um sie Tests zur \u00dcberpr\u00fcfung der Datenqualit\u00e4t zu unterziehen. Durch die strikte Trennung der Komponenten - dem Auslesen der Daten einerseits, den Checks andererseits und schlie\u00dflich der Kommunkation zwischen den eben genannten -   ist es leicht um weitere Tools erweiterbar.\r\n\r\nMit einer OpenAPI-Definition f\u00fcr die Programmierschnittstelle k\u00f6nnen die durch museum-digital:qa verf\u00fcgbar gemachten Tools einfach durch Softwareanbieter und Forschende nachgenutzt werden.",
-        "tech_background_text": "museum-digital:qa nimmt Daten aus g\u00e4ngigen und konsistent vorliegenden Eingabeformaten entgegen, bringt diese in ein internes, einheitliches Format, um diese schlie\u00dflich hinsichtlich ihrer Vollst\u00e4ndigkeit und Plausibilit\u00e4t auszuwerten. Eingabeformate k\u00f6nnen einerseits die Ausgabe- und Exportformate von verschiedenen Sammlungsmanagementsystemen, so diese f\u00fcr alle das Programm nutzenden Museen gleich geformt sind, oder die g\u00e4ngigen Austauschformate f\u00fcr Objektdaten sein. \r\n\r\nDie \u00fcblichen Sammlungsmanagementsysteme haben verschiedene Ans\u00e4tze, um mit spezifischen Anpassungen der Datenbank an einzelne Museen umzugehen. W\u00e4hrend museum-digital:musdb gezielt keine vom Museum selbst definierten Felder zul\u00e4sst, um eine konsistente Datenbankgestaltung \u00fcber Institutionsgrenzen hinweg zu erm\u00f6glichen, und so einerseits eine Vielzahl von Auswertungsfunktionen, die auf die Feldauswahl zugeschnitten sind anbieten zu k\u00f6nnen, und andererseits Export- und Suchfunktionen \u00fcber mehrere Museen hinweg zu erm\u00f6glichen, sind andere Sammlungsmanagementsysteme auch intern deutlich st\u00e4rker auf die sie nutzenden Museen zugeschnitten. Diese Anpassbarkeit kann entweder auf Ebene der Benutzeroberfl\u00e4che oder direkt auf der Ebene der Datenbankstruktur vorliegen. Ist auch die Datenbankstruktur anpassbar, hei\u00dft das gleichzeitig, dass die Exporte aus derselben Software je nach Museum sehr unterschiedlich geformt sein k\u00f6nnen. Wo nur die Benutzeroberfl\u00e4che angepasst wird, gibt es oft softwarespezifische Standard-Exportformate, die \u00fcber Museumsgrenzen hinweg konsistent geformt, gut gewartet und ggfs. vollst\u00e4ndiger als andere Exportoptionen sind (und somit etwa f\u00fcr eine Migration der Daten besonders gut geeignet sind).\r\n\r\nUm den Austausch von Daten \u00fcber Institutions- und Softwaregrenzen hinweg zu vereinfachen, haben sich verschiedene offene (Austausch-)Standards etabliert. Der f\u00fcr Museen sicherlich wichtigste ist dabei LIDO, in angrenzenden Bereichen werden etwa EAD (v.a. Archive) und MODS (v.a. Bibliotheken) verwendet. Diese Standards sind in den meisten F\u00e4llen f\u00fcr den Austausch ver\u00f6ffentlichbarer Daten gedacht, decken also in den seltensten F\u00e4llen alle lokal vorhandenen Datenfelder ab. Offene Standards sind andererseits in vielen Sammlungsmanagement-L\u00f6sungen implementiert. Mit dem 2023 ver\u00f6ffentlichten EODEM sind im Museumsbereich erste Schritte zu erkennen, auch prim\u00e4r interne Daten standardisiert austauschbar zu machen.\r\n\r\nZum Zwecke des Importierens von Daten (sei es zur Migration der Daten f\u00fcr die Inventarisierung oder zur Ver\u00f6ffentlichung) bietet museum-digital ein Import-Tool, das neben den g\u00e4ngigen Austauschformaten auch einige software-spezifische Formate beherrscht (einerseits, weil nicht alle Sammlungsmanagementsysteme die g\u00e4ngigen Austauschformate \"von Haus aus\" unterst\u00fctzen, anderseits, weil diese wie oben besprochen oft vollst\u00e4ndiger sind). Dieses Import-Tool besteht seinerseits aus drei Komponenten: 1) grundlegenden, f\u00fcr die Museumarbeit relevanten Datentypen (etwa Objekt, Schlagwort, Leihverkehr), 2) Funktionen zum Auslesen von Daten aus den erw\u00e4hnten Formaten und die \u00dcberf\u00fchrung der Eingabedaten in die eben genannten Datentypen, und 3) einem Modul zum tats\u00e4chlichen \u00dcberf\u00fchren der Daten in die Datenbank.\r\n\r\nDie Importer-Module zur Definition der Datentypen und zum Auslesen der Daten aus verschiedenen Eingabeformaten werden in museum-digital:qa nachgenutzt. So kann museum-digital:qa mit wenigen Anpassungen alle Importformate, die auch der Importer von museum-digital unterst\u00fctzt, unterst\u00fctzen (bei museumsspezifischen Importformaten lohnt es sich allerdings nicht, diese Anpassungen zu unternehmen). Ohne relevanten eigenen Code f\u00fcr das Auslesen der eingehenden Daten bleibt museum-digital:qa somit zudem sehr wartungsarm. Umgekehrt bedeutet die Nachnutzung des Auslese-Teils des Importers auch, dass alle Daten, die mit museum-digital:qa auf ihre Qualit\u00e4t \u00fcberpr\u00fcft werden k\u00f6nnen, ohne weitere Anpassungen in museum-digital importiert werden k\u00f6nnen.\r\n\r\nDie eingelesenen Daten liegen in der Folge in einer strukturierten Form vor und k\u00f6nnen verh\u00e4ltnism\u00e4\u00dfig einfach weiter verarbeitet werden, indem sie - leicht umformuliert - an die Funktionen zur \u00dcberpr\u00fcfung der Datenqualit\u00e4t weitergegeben werden. Diese Funktionen wurden im Zuge der Arbeit an museum-digital:qa aus museum-digital:musdb in eine eigene Open-Source-Bibliothek ausgelagert."
+        "tech_background_text": "museum-digital:qa nimmt Daten aus g\u00e4ngigen und konsistent vorliegenden Eingabeformaten entgegen, bringt diese in ein internes, einheitliches Format, um diese schlie\u00dflich hinsichtlich ihrer Vollst\u00e4ndigkeit und Plausibilit\u00e4t auszuwerten. Eingabeformate k\u00f6nnen einerseits die Ausgabe- und Exportformate von verschiedenen Sammlungsmanagementsystemen, so diese f\u00fcr alle das Programm nutzenden Museen gleich geformt sind, oder die g\u00e4ngigen Austauschformate f\u00fcr Objektdaten sein. \r\n\r\nDie \u00fcblichen Sammlungsmanagementsysteme haben verschiedene Ans\u00e4tze, um mit spezifischen Anpassungen der Datenbank an einzelne Museen umzugehen. W\u00e4hrend museum-digital:musdb gezielt keine vom Museum selbst definierten Felder zul\u00e4sst, um eine konsistente Datenbankgestaltung \u00fcber Institutionsgrenzen hinweg zu erm\u00f6glichen, und so einerseits eine Vielzahl von Auswertungsfunktionen, die auf die Feldauswahl zugeschnitten sind anbieten zu k\u00f6nnen, und andererseits Export- und Suchfunktionen \u00fcber mehrere Museen hinweg zu erm\u00f6glichen, sind andere Sammlungsmanagementsysteme auch intern deutlich st\u00e4rker auf die sie nutzenden Museen zugeschnitten. Diese Anpassbarkeit kann entweder auf Ebene der Benutzeroberfl\u00e4che oder direkt auf der Ebene der Datenbankstruktur vorliegen. Ist auch die Datenbankstruktur anpassbar, hei\u00dft das gleichzeitig, dass die Exporte aus derselben Software je nach Museum sehr unterschiedlich geformt sein k\u00f6nnen. Wo nur die Benutzeroberfl\u00e4che angepasst wird, gibt es oft softwarespezifische Standard-Exportformate, die \u00fcber Museumsgrenzen hinweg konsistent geformt, gut gewartet und ggfs. vollst\u00e4ndiger als andere Exportoptionen sind (und somit etwa f\u00fcr eine Migration der Daten besonders gut geeignet sind).\r\n\r\nUm den Austausch von Daten \u00fcber Institutions- und Softwaregrenzen hinweg zu vereinfachen, haben sich verschiedene offene (Austausch-)Standards etabliert. Der f\u00fcr Museen sicherlich wichtigste ist dabei LIDO, in angrenzenden Bereichen werden etwa EAD (v.a. Archive) und MODS (v.a. Bibliotheken) verwendet. Diese Standards sind in den meisten F\u00e4llen f\u00fcr den Austausch ver\u00f6ffentlichbarer Daten gedacht, decken also in den seltensten F\u00e4llen alle lokal vorhandenen Datenfelder ab. Offene Standards sind andererseits in vielen Sammlungsmanagement-L\u00f6sungen implementiert. Mit dem 2023 ver\u00f6ffentlichten EODEM sind im Museumsbereich erste Schritte zu erkennen, auch prim\u00e4r interne Daten standardisiert austauschbar zu machen.\r\n\r\nZum Zwecke des Importierens von Daten (sei es zur Migration der Daten f\u00fcr die Inventarisierung oder zur Ver\u00f6ffentlichung) bietet museum-digital ein Import-Tool, das neben den g\u00e4ngigen Austauschformaten auch einige software-spezifische Formate beherrscht (einerseits, weil nicht alle Sammlungsmanagementsysteme die g\u00e4ngigen Austauschformate \"von Haus aus\" unterst\u00fctzen, anderseits, weil diese wie oben besprochen oft vollst\u00e4ndiger sind). Dieses Import-Tool besteht seinerseits aus drei Komponenten: 1) grundlegenden, f\u00fcr die Museumarbeit relevanten Datentypen (etwa Objekt, Schlagwort, Leihverkehr), 2) Funktionen zum Auslesen von Daten aus den erw\u00e4hnten Formaten und die \u00dcberf\u00fchrung der Eingabedaten in die eben genannten Datentypen, und 3) einem Modul zum tats\u00e4chlichen \u00dcberf\u00fchren der Daten in die Datenbank.\r\n\r\nDie Importer-Module zur Definition der Datentypen und zum Auslesen der Daten aus verschiedenen Eingabeformaten werden in museum-digital:qa nachgenutzt. So kann museum-digital:qa mit wenigen Anpassungen alle Importformate, die auch der Importer von museum-digital unterst\u00fctzt, unterst\u00fctzen (bei museumsspezifischen Importformaten lohnt es sich allerdings nicht, diese Anpassungen zu unternehmen). Ohne relevanten eigenen Code f\u00fcr das Auslesen der eingehenden Daten bleibt museum-digital:qa somit zudem sehr wartungsarm. Umgekehrt bedeutet die Nachnutzung des Auslese-Teils des Importers auch, dass alle Daten, die mit museum-digital:qa auf ihre Qualit\u00e4t \u00fcberpr\u00fcft werden k\u00f6nnen, ohne weitere Anpassungen in museum-digital importiert werden k\u00f6nnen.\r\n\r\nDie eingelesenen Daten liegen in der Folge in einer strukturierten Form vor und k\u00f6nnen verh\u00e4ltnism\u00e4\u00dfig einfach weiter verarbeitet werden, indem sie - leicht umformuliert - an die Funktionen zur \u00dcberpr\u00fcfung der Datenqualit\u00e4t weitergegeben werden. Diese Funktionen wurden im Zuge der Arbeit an museum-digital:qa aus museum-digital:musdb in eine eigene Open-Source-Bibliothek ausgelagert.",
+        "go_back": "Zur\u00fcck",
+        "paste_as_text": "Als Text einf\u00fcgen",
+        "licensed_under": "Dieses Werk ist lizensiert nach",
+        "reload_application": "Anwendung neu laden",
+        "more": "Weiteres",
+        "select_check": "Bitte w\u00e4hlen Sie die Art der auszuf\u00fchrenden Pr\u00fcfung",
+        "minimaldatensatz_p1": "Die AG Minimaldatensatz hat es sich zum Ziel gesetzt, eine Auswahl von Informationseinheiten zu definieren, die f\u00fcr eine sinnvolle Publikation von Objektdaten zwingend notwendig oder zumindest dringend empfohlen sind. Dabei zielen die Empfehlungen der AG besonders auf die Publikation der Daten in der Deutschen Digitalen Bibliothek (DDB) ab - sie k\u00f6nnen aber auch dar\u00fcber hinaus als eine sinnvoller Mindest-Ausgangswert genutzt werden.",
+        "minimaldatensatz_p2": "Weil der Kontext der AG Minimaldatensatz spezifisch deutsch ist, sind auch die R\u00fcckgabewerte der Pr\u00fcfung vorerst nur auf Deutsch verf\u00fcgbar.",
+        "see_also": "Siehe auch",
+        "log": "Zeitleiste",
+        "launch": "Launch",
+        "thanks": "Danksagung"
     }
 }

quality-web/en/quality_web.json

@@ -45,6 +45,18 @@
         "faq_q_birth_death_dates_via_vocabs": "Birth and death dates of related actors are not covered by our object metadata, but we do link them to norm data repositories. Will the plausibility checks still work?",
         "faq_a_birth_death_dates_via_vocabs": "Yes. museum-digital:qa will also check references to norm data repositories against museum-digital's controlled vocabularies to gather additional data - such as birth and death dates - if any such references are supplied.",
         "outlook_text": "museum-digital:qa offers a platform to parse and process museum data from a multitude of sources - specifically, to check them for their quality. The strictly modularization of components - the parsing of the data on one hand, the checks themselves on the other, and finally the communication between these two - makes it simple to integrate further tools and checks.\r\n\r\nUsing the API, specified using the OpenAPI format, researchers and software vendors can easily reuse the tools made accessible through museum-digital:qa.",
-        "tech_background_text": "museum-digital:qa accepts data from common and consistent input formats, converts them into an internal, uniform format, and finally evaluates them with regard to their completeness and plausibility. Input formats may either be the software-specific export formats of various collection management systems, if these are formed in the same way across all museums using the same application, or the common open standards for the exchange of museum object data. \r\n\r\nDifferent collection management systems have different approaches to dealing with the task of customization. While museum-digital:musdb purposefully does not allow museums to freely define fields in order to ensure a consistent database design across institutional boundaries, and thus to be able to offer a variety of evaluation functions tailored to the shared set of data fields on the one hand, and to enable export and search functions across multiple museums on the other hand, other collection management systems allow customization up to the level of defining a fully custom database structure. This customizability may either work on the user interface level or directly at level of the underlying database. If the database structure is also customizable, this simultaneously means that exports from the same software can come in a variety of formats similarly custom to the given museum. Where only the user interface is customizable, there are often software-specific export formats that are consistent across museum boundaries, well maintained, and possibly more complete than other export options (and thus particularly well suited for data migration, for example).\r\n\r\nIn order to simplify the exchange of data across institutional and software boundaries, various open standards have been developed. The single one most relevant for museums is certainly LIDO; in related areas, EAD (mainly archives) and MODS (mainly libraries) are used. In most cases, these standards are intended for the exchange of publishable data. They thus rarely cover all locally available data fields. Open standards, on the other hand, are implemented in many collection management solutions. With the EODEM published in 2023, early steps towards fascilitating the exchange of primarily internal data have begun to be taken.\r\n\r\nFor the purpose of importing data (be it for data migration or simply for publication), museum-digital offers an import tool that - in addition to the common exchange formats - also supports some software-specific formats (on the one hand, because not all collection management systems support the common exchange formats \"out of the box\", on the other hand, because these are often more complete, as discussed above). This import tool, in turn, consists of three components: 1) basic data types relevant to museum work (such as object, keyword, loan), 2) functions for reading data from the aforementioned formats and transferring the input data into the data types just mentioned, and 3) a module for actually transferring the data into the database.\r\n\r\nThe import tool's modules for defining data types and parsing data from different input formats are reused in museum-digital:qa. Thus, museum-digital:qa can support all import formats that are also supported by the importer of museum-digital with a minimum of additional effor (for museum-specific import formats, however, it is not worthwhile to undertake such adaptations). Without relevant own code for reading the incoming data, museum-digital:qa thus also remains very low-maintenance. Conversely, reusing the parsing functionalities of the importer also means that all data that can be checked for quality using museum-digital:qa can be imported into museum-digital without any further adjustments as well.\r\n\r\nThe input data are subsequently available in a structured form and can easily be processed further. Here, it is passed on in a slightly adapted form to the functions for checking data quality. As museum-digital:qa was written, these functions were moved from museum-digital:musdb to a separate library into a standalone, open-source library."
+        "tech_background_text": "museum-digital:qa accepts data from common and consistent input formats, converts them into an internal, uniform format, and finally evaluates them with regard to their completeness and plausibility. Input formats may either be the software-specific export formats of various collection management systems, if these are formed in the same way across all museums using the same application, or the common open standards for the exchange of museum object data. \r\n\r\nDifferent collection management systems have different approaches to dealing with the task of customization. While museum-digital:musdb purposefully does not allow museums to freely define fields in order to ensure a consistent database design across institutional boundaries, and thus to be able to offer a variety of evaluation functions tailored to the shared set of data fields on the one hand, and to enable export and search functions across multiple museums on the other hand, other collection management systems allow customization up to the level of defining a fully custom database structure. This customizability may either work on the user interface level or directly at level of the underlying database. If the database structure is also customizable, this simultaneously means that exports from the same software can come in a variety of formats similarly custom to the given museum. Where only the user interface is customizable, there are often software-specific export formats that are consistent across museum boundaries, well maintained, and possibly more complete than other export options (and thus particularly well suited for data migration, for example).\r\n\r\nIn order to simplify the exchange of data across institutional and software boundaries, various open standards have been developed. The single one most relevant for museums is certainly LIDO; in related areas, EAD (mainly archives) and MODS (mainly libraries) are used. In most cases, these standards are intended for the exchange of publishable data. They thus rarely cover all locally available data fields. Open standards, on the other hand, are implemented in many collection management solutions. With the EODEM published in 2023, early steps towards fascilitating the exchange of primarily internal data have begun to be taken.\r\n\r\nFor the purpose of importing data (be it for data migration or simply for publication), museum-digital offers an import tool that - in addition to the common exchange formats - also supports some software-specific formats (on the one hand, because not all collection management systems support the common exchange formats \"out of the box\", on the other hand, because these are often more complete, as discussed above). This import tool, in turn, consists of three components: 1) basic data types relevant to museum work (such as object, keyword, loan), 2) functions for reading data from the aforementioned formats and transferring the input data into the data types just mentioned, and 3) a module for actually transferring the data into the database.\r\n\r\nThe import tool's modules for defining data types and parsing data from different input formats are reused in museum-digital:qa. Thus, museum-digital:qa can support all import formats that are also supported by the importer of museum-digital with a minimum of additional effor (for museum-specific import formats, however, it is not worthwhile to undertake such adaptations). Without relevant own code for reading the incoming data, museum-digital:qa thus also remains very low-maintenance. Conversely, reusing the parsing functionalities of the importer also means that all data that can be checked for quality using museum-digital:qa can be imported into museum-digital without any further adjustments as well.\r\n\r\nThe input data are subsequently available in a structured form and can easily be processed further. Here, it is passed on in a slightly adapted form to the functions for checking data quality. As museum-digital:qa was written, these functions were moved from museum-digital:musdb to a separate library into a standalone, open-source library.",
+        "go_back": "Go back",
+        "paste_as_text": "Paste in plain text",
+        "licensed_under": "This work is licensed under",
+        "reload_application": "Reload application",
+        "more": "More",
+        "select_check": "Please select the type of check(s) to run",
+        "minimaldatensatz_p1": "The Working Group Minimaldatensatz (\"Minimum Viable Object Record\") sets out to define a set of basic object information required or highly recommended for a worthwhile publication of objects. Its recommendations are primarily aimed at publishing in the German Digital Library (DDB), but can serve as a sane guideline in other contexts as well.",
+        "minimaldatensatz_p2": "As the context of this check is specifically German, the return values of the check are thus far available only in German.",
+        "see_also": "See also",
+        "log": "Log",
+        "launch": "Launch",
+        "thanks": "Thanks"
     }
 }

quality-web/hu/quality_web.json

@@ -45,6 +45,18 @@
         "faq_q_birth_death_dates_via_vocabs": "Birth and death dates of related actors are not covered by our object metadata, but we do link them to norm data repositories. Will the plausibility checks still work?",
         "faq_a_birth_death_dates_via_vocabs": "Yes. museum-digital:qa will also check references to norm data repositories against museum-digital's controlled vocabularies to gather additional data - such as birth and death dates - if any such references are supplied.",
         "outlook_text": "museum-digital:qa offers a platform to parse and process museum data from a multitude of sources - specifically, to check them for their quality. The strictly modularization of components - the parsing of the data on one hand, the checks themselves on the other, and finally the communication between these two - makes it simple to integrate further tools and checks.\r\n\r\nUsing the API, specified using the OpenAPI format, researchers and software vendors can easily reuse the tools made accessible through museum-digital:qa.",
-        "tech_background_text": "museum-digital:qa accepts data from common and consistent input formats, converts them into an internal, uniform format, and finally evaluates them with regard to their completeness and plausibility. Input formats may either be the software-specific export formats of various collection management systems, if these are formed in the same way across all museums using the same application, or the common open standards for the exchange of museum object data. \r\n\r\nDifferent collection management systems have different approaches to dealing with the task of customization. While museum-digital:musdb purposefully does not allow museums to freely define fields in order to ensure a consistent database design across institutional boundaries, and thus to be able to offer a variety of evaluation functions tailored to the shared set of data fields on the one hand, and to enable export and search functions across multiple museums on the other hand, other collection management systems allow customization up to the level of defining a fully custom database structure. This customizability may either work on the user interface level or directly at level of the underlying database. If the database structure is also customizable, this simultaneously means that exports from the same software can come in a variety of formats similarly custom to the given museum. Where only the user interface is customizable, there are often software-specific export formats that are consistent across museum boundaries, well maintained, and possibly more complete than other export options (and thus particularly well suited for data migration, for example).\r\n\r\nIn order to simplify the exchange of data across institutional and software boundaries, various open standards have been developed. The single one most relevant for museums is certainly LIDO; in related areas, EAD (mainly archives) and MODS (mainly libraries) are used. In most cases, these standards are intended for the exchange of publishable data. They thus rarely cover all locally available data fields. Open standards, on the other hand, are implemented in many collection management solutions. With the EODEM published in 2023, early steps towards fascilitating the exchange of primarily internal data have begun to be taken.\r\n\r\nFor the purpose of importing data (be it for data migration or simply for publication), museum-digital offers an import tool that - in addition to the common exchange formats - also supports some software-specific formats (on the one hand, because not all collection management systems support the common exchange formats \"out of the box\", on the other hand, because these are often more complete, as discussed above). This import tool, in turn, consists of three components: 1) basic data types relevant to museum work (such as object, keyword, loan), 2) functions for reading data from the aforementioned formats and transferring the input data into the data types just mentioned, and 3) a module for actually transferring the data into the database.\r\n\r\nThe import tool's modules for defining data types and parsing data from different input formats are reused in museum-digital:qa. Thus, museum-digital:qa can support all import formats that are also supported by the importer of museum-digital with a minimum of additional effor (for museum-specific import formats, however, it is not worthwhile to undertake such adaptations). Without relevant own code for reading the incoming data, museum-digital:qa thus also remains very low-maintenance. Conversely, reusing the parsing functionalities of the importer also means that all data that can be checked for quality using museum-digital:qa can be imported into museum-digital without any further adjustments as well.\r\n\r\nThe input data are subsequently available in a structured form and can easily be processed further. Here, it is passed on in a slightly adapted form to the functions for checking data quality. As museum-digital:qa was written, these functions were moved from museum-digital:musdb to a separate library into a standalone, open-source library."
+        "tech_background_text": "museum-digital:qa accepts data from common and consistent input formats, converts them into an internal, uniform format, and finally evaluates them with regard to their completeness and plausibility. Input formats may either be the software-specific export formats of various collection management systems, if these are formed in the same way across all museums using the same application, or the common open standards for the exchange of museum object data. \r\n\r\nDifferent collection management systems have different approaches to dealing with the task of customization. While museum-digital:musdb purposefully does not allow museums to freely define fields in order to ensure a consistent database design across institutional boundaries, and thus to be able to offer a variety of evaluation functions tailored to the shared set of data fields on the one hand, and to enable export and search functions across multiple museums on the other hand, other collection management systems allow customization up to the level of defining a fully custom database structure. This customizability may either work on the user interface level or directly at level of the underlying database. If the database structure is also customizable, this simultaneously means that exports from the same software can come in a variety of formats similarly custom to the given museum. Where only the user interface is customizable, there are often software-specific export formats that are consistent across museum boundaries, well maintained, and possibly more complete than other export options (and thus particularly well suited for data migration, for example).\r\n\r\nIn order to simplify the exchange of data across institutional and software boundaries, various open standards have been developed. The single one most relevant for museums is certainly LIDO; in related areas, EAD (mainly archives) and MODS (mainly libraries) are used. In most cases, these standards are intended for the exchange of publishable data. They thus rarely cover all locally available data fields. Open standards, on the other hand, are implemented in many collection management solutions. With the EODEM published in 2023, early steps towards fascilitating the exchange of primarily internal data have begun to be taken.\r\n\r\nFor the purpose of importing data (be it for data migration or simply for publication), museum-digital offers an import tool that - in addition to the common exchange formats - also supports some software-specific formats (on the one hand, because not all collection management systems support the common exchange formats \"out of the box\", on the other hand, because these are often more complete, as discussed above). This import tool, in turn, consists of three components: 1) basic data types relevant to museum work (such as object, keyword, loan), 2) functions for reading data from the aforementioned formats and transferring the input data into the data types just mentioned, and 3) a module for actually transferring the data into the database.\r\n\r\nThe import tool's modules for defining data types and parsing data from different input formats are reused in museum-digital:qa. Thus, museum-digital:qa can support all import formats that are also supported by the importer of museum-digital with a minimum of additional effor (for museum-specific import formats, however, it is not worthwhile to undertake such adaptations). Without relevant own code for reading the incoming data, museum-digital:qa thus also remains very low-maintenance. Conversely, reusing the parsing functionalities of the importer also means that all data that can be checked for quality using museum-digital:qa can be imported into museum-digital without any further adjustments as well.\r\n\r\nThe input data are subsequently available in a structured form and can easily be processed further. Here, it is passed on in a slightly adapted form to the functions for checking data quality. As museum-digital:qa was written, these functions were moved from museum-digital:musdb to a separate library into a standalone, open-source library.",
+        "go_back": "Go back",
+        "paste_as_text": "Paste in plain text",
+        "licensed_under": "This work is licensed under",
+        "reload_application": "Reload application",
+        "more": "More",
+        "select_check": "Please select the type of check(s) to run",
+        "minimaldatensatz_p1": "The Working Group Minimaldatensatz (\"Minimum Viable Object Record\") sets out to define a set of basic object information required or highly recommended for a worthwhile publication of objects. Its recommendations are primarily aimed at publishing in the German Digital Library (DDB), but can serve as a sane guideline in other contexts as well.",
+        "minimaldatensatz_p2": "As the context of this check is specifically German, the return values of the check are thus far available only in German.",
+        "see_also": "See also",
+        "log": "Log",
+        "launch": "Launch",
+        "thanks": "Thanks"
     }
 }

quality-web/ru/quality_web.json

@@ -45,6 +45,18 @@
         "faq_q_birth_death_dates_via_vocabs": "Birth and death dates of related actors are not covered by our object metadata, but we do link them to norm data repositories. Will the plausibility checks still work?",
         "faq_a_birth_death_dates_via_vocabs": "Yes. museum-digital:qa will also check references to norm data repositories against museum-digital's controlled vocabularies to gather additional data - such as birth and death dates - if any such references are supplied.",
         "outlook_text": "museum-digital:qa offers a platform to parse and process museum data from a multitude of sources - specifically, to check them for their quality. The strictly modularization of components - the parsing of the data on one hand, the checks themselves on the other, and finally the communication between these two - makes it simple to integrate further tools and checks.\r\n\r\nUsing the API, specified using the OpenAPI format, researchers and software vendors can easily reuse the tools made accessible through museum-digital:qa.",
-        "tech_background_text": "museum-digital:qa accepts data from common and consistent input formats, converts them into an internal, uniform format, and finally evaluates them with regard to their completeness and plausibility. Input formats may either be the software-specific export formats of various collection management systems, if these are formed in the same way across all museums using the same application, or the common open standards for the exchange of museum object data. \r\n\r\nDifferent collection management systems have different approaches to dealing with the task of customization. While museum-digital:musdb purposefully does not allow museums to freely define fields in order to ensure a consistent database design across institutional boundaries, and thus to be able to offer a variety of evaluation functions tailored to the shared set of data fields on the one hand, and to enable export and search functions across multiple museums on the other hand, other collection management systems allow customization up to the level of defining a fully custom database structure. This customizability may either work on the user interface level or directly at level of the underlying database. If the database structure is also customizable, this simultaneously means that exports from the same software can come in a variety of formats similarly custom to the given museum. Where only the user interface is customizable, there are often software-specific export formats that are consistent across museum boundaries, well maintained, and possibly more complete than other export options (and thus particularly well suited for data migration, for example).\r\n\r\nIn order to simplify the exchange of data across institutional and software boundaries, various open standards have been developed. The single one most relevant for museums is certainly LIDO; in related areas, EAD (mainly archives) and MODS (mainly libraries) are used. In most cases, these standards are intended for the exchange of publishable data. They thus rarely cover all locally available data fields. Open standards, on the other hand, are implemented in many collection management solutions. With the EODEM published in 2023, early steps towards fascilitating the exchange of primarily internal data have begun to be taken.\r\n\r\nFor the purpose of importing data (be it for data migration or simply for publication), museum-digital offers an import tool that - in addition to the common exchange formats - also supports some software-specific formats (on the one hand, because not all collection management systems support the common exchange formats \"out of the box\", on the other hand, because these are often more complete, as discussed above). This import tool, in turn, consists of three components: 1) basic data types relevant to museum work (such as object, keyword, loan), 2) functions for reading data from the aforementioned formats and transferring the input data into the data types just mentioned, and 3) a module for actually transferring the data into the database.\r\n\r\nThe import tool's modules for defining data types and parsing data from different input formats are reused in museum-digital:qa. Thus, museum-digital:qa can support all import formats that are also supported by the importer of museum-digital with a minimum of additional effor (for museum-specific import formats, however, it is not worthwhile to undertake such adaptations). Without relevant own code for reading the incoming data, museum-digital:qa thus also remains very low-maintenance. Conversely, reusing the parsing functionalities of the importer also means that all data that can be checked for quality using museum-digital:qa can be imported into museum-digital without any further adjustments as well.\r\n\r\nThe input data are subsequently available in a structured form and can easily be processed further. Here, it is passed on in a slightly adapted form to the functions for checking data quality. As museum-digital:qa was written, these functions were moved from museum-digital:musdb to a separate library into a standalone, open-source library."
+        "tech_background_text": "museum-digital:qa accepts data from common and consistent input formats, converts them into an internal, uniform format, and finally evaluates them with regard to their completeness and plausibility. Input formats may either be the software-specific export formats of various collection management systems, if these are formed in the same way across all museums using the same application, or the common open standards for the exchange of museum object data. \r\n\r\nDifferent collection management systems have different approaches to dealing with the task of customization. While museum-digital:musdb purposefully does not allow museums to freely define fields in order to ensure a consistent database design across institutional boundaries, and thus to be able to offer a variety of evaluation functions tailored to the shared set of data fields on the one hand, and to enable export and search functions across multiple museums on the other hand, other collection management systems allow customization up to the level of defining a fully custom database structure. This customizability may either work on the user interface level or directly at level of the underlying database. If the database structure is also customizable, this simultaneously means that exports from the same software can come in a variety of formats similarly custom to the given museum. Where only the user interface is customizable, there are often software-specific export formats that are consistent across museum boundaries, well maintained, and possibly more complete than other export options (and thus particularly well suited for data migration, for example).\r\n\r\nIn order to simplify the exchange of data across institutional and software boundaries, various open standards have been developed. The single one most relevant for museums is certainly LIDO; in related areas, EAD (mainly archives) and MODS (mainly libraries) are used. In most cases, these standards are intended for the exchange of publishable data. They thus rarely cover all locally available data fields. Open standards, on the other hand, are implemented in many collection management solutions. With the EODEM published in 2023, early steps towards fascilitating the exchange of primarily internal data have begun to be taken.\r\n\r\nFor the purpose of importing data (be it for data migration or simply for publication), museum-digital offers an import tool that - in addition to the common exchange formats - also supports some software-specific formats (on the one hand, because not all collection management systems support the common exchange formats \"out of the box\", on the other hand, because these are often more complete, as discussed above). This import tool, in turn, consists of three components: 1) basic data types relevant to museum work (such as object, keyword, loan), 2) functions for reading data from the aforementioned formats and transferring the input data into the data types just mentioned, and 3) a module for actually transferring the data into the database.\r\n\r\nThe import tool's modules for defining data types and parsing data from different input formats are reused in museum-digital:qa. Thus, museum-digital:qa can support all import formats that are also supported by the importer of museum-digital with a minimum of additional effor (for museum-specific import formats, however, it is not worthwhile to undertake such adaptations). Without relevant own code for reading the incoming data, museum-digital:qa thus also remains very low-maintenance. Conversely, reusing the parsing functionalities of the importer also means that all data that can be checked for quality using museum-digital:qa can be imported into museum-digital without any further adjustments as well.\r\n\r\nThe input data are subsequently available in a structured form and can easily be processed further. Here, it is passed on in a slightly adapted form to the functions for checking data quality. As museum-digital:qa was written, these functions were moved from museum-digital:musdb to a separate library into a standalone, open-source library.",
+        "go_back": "Go back",
+        "paste_as_text": "Paste in plain text",
+        "licensed_under": "This work is licensed under",
+        "reload_application": "Reload application",
+        "more": "More",
+        "select_check": "Please select the type of check(s) to run",
+        "minimaldatensatz_p1": "The Working Group Minimaldatensatz (\"Minimum Viable Object Record\") sets out to define a set of basic object information required or highly recommended for a worthwhile publication of objects. Its recommendations are primarily aimed at publishing in the German Digital Library (DDB), but can serve as a sane guideline in other contexts as well.",
+        "minimaldatensatz_p2": "As the context of this check is specifically German, the return values of the check are thus far available only in German.",
+        "see_also": "See also",
+        "log": "Log",
+        "launch": "Launch",
+        "thanks": "Thanks"
     }
 }

value-sets/ar/object_damage_types_set.json

@@ -1,6 +1,7 @@
 {
     "object_damage_types_set": {
         "water_damage": "Water damage",
-        "breakage": "Breakage"
+        "breakage": "Breakage",
+        "desiccation": "Desiccation"
     }
 }

value-sets/de/object_damage_types_set.json

@@ -1,6 +1,7 @@
 {
     "object_damage_types_set": {
         "water_damage": "Wasserschaden",
-        "breakage": "Bruchschaden"
+        "breakage": "Bruchschaden",
+        "desiccation": "Austrocknung"
     }
 }

value-sets/dsb/object_damage_types_set.json

@@ -1,6 +1,7 @@
 {
     "object_damage_types_set": {
         "water_damage": "Water damage",
-        "breakage": "Breakage"
+        "breakage": "Breakage",
+        "desiccation": "Desiccation"
     }
 }

value-sets/en/object_damage_types_set.json

@@ -1,6 +1,7 @@
 {
     "object_damage_types_set": {
         "water_damage": "Water damage",
-        "breakage": "Breakage"
+        "breakage": "Breakage",
+        "desiccation": "Desiccation"
     }
 }

value-sets/es/object_damage_types_set.json

@@ -1,6 +1,7 @@
 {
     "object_damage_types_set": {
         "water_damage": "Water damage",
-        "breakage": "Breakage"
+        "breakage": "Breakage",
+        "desiccation": "Desiccation"
     }
 }

value-sets/fr/object_damage_types_set.json

@@ -1,6 +1,7 @@
 {
     "object_damage_types_set": {
         "water_damage": "Water damage",
-        "breakage": "Breakage"
+        "breakage": "Breakage",
+        "desiccation": "Desiccation"
     }
 }

value-sets/hsb/object_damage_types_set.json

@@ -1,6 +1,7 @@
 {
     "object_damage_types_set": {
         "water_damage": "Water damage",
-        "breakage": "Breakage"
+        "breakage": "Breakage",
+        "desiccation": "Desiccation"
     }
 }

value-sets/hu/object_damage_types_set.json

@@ -1,6 +1,7 @@
 {
     "object_damage_types_set": {
         "water_damage": "V\u00edzk\u00e1r",
-        "breakage": "T\u00f6r\u00e9s"
+        "breakage": "T\u00f6r\u00e9s",
+        "desiccation": "Desiccation"
     }
 }

value-sets/id/object_damage_types_set.json

@@ -1,6 +1,7 @@
 {
     "object_damage_types_set": {
         "water_damage": "Water damage",
-        "breakage": "Breakage"
+        "breakage": "Breakage",
+        "desiccation": "Desiccation"
     }
 }

value-sets/it/object_damage_types_set.json

@@ -1,6 +1,7 @@
 {
     "object_damage_types_set": {
         "water_damage": "danno causato dall\u2019acqua ",
-        "breakage": "danno da rottura"
+        "breakage": "danno da rottura",
+        "desiccation": "Desiccation"
     }
 }

value-sets/iw/object_damage_types_set.json

@@ -1,6 +1,7 @@
 {
     "object_damage_types_set": {
         "water_damage": "Water damage",
-        "breakage": "Breakage"
+        "breakage": "Breakage",
+        "desiccation": "Desiccation"
     }
 }

value-sets/nl/object_damage_types_set.json

@@ -1,6 +1,7 @@
 {
     "object_damage_types_set": {
         "water_damage": "Water damage",
-        "breakage": "Breakage"
+        "breakage": "Breakage",
+        "desiccation": "Desiccation"
     }
 }

value-sets/pl/object_damage_types_set.json

@@ -1,6 +1,7 @@
 {
     "object_damage_types_set": {
         "water_damage": "Water damage",
-        "breakage": "Breakage"
+        "breakage": "Breakage",
+        "desiccation": "Desiccation"
     }
 }