{
    "quality_web": {
        "puqi": "Publik\u00e1ci\u00f3s min\u0151s\u00e9gi index (PuQI)",
        "plausi": "Plauzabilit\u00e1s ellen\u0151rz\u00e9s",
        "plausi_legal": "A k\u00e9pek \/ \u00e1br\u00e1zol\u00e1sok licenc st\u00e1tusz\u00e1nak plauzibilit\u00e1si ellen\u0151rz\u00e9se",
        "puqi_explica": "A publlik\u00e1ci\u00f3s min\u0151s\u00e9gi index (Publication Quality Index - PuQI) egy rekord publik\u00e1lhat\u00f3 inform\u00e1ci\u00f3inak teljess\u00e9g\u00e9t \u00e9s megfelel\u0151s\u00e9g\u00e9t m\u00e9ri. P\u00e9ld\u00e1ul visszajelz\u00e9st ad a t\u00e1rgy megnevez\u00e9s\u00e9nek \u00e9s kulcsszavainak el\u00e9rhet\u0151s\u00e9g\u00e9r\u0151l. A t\u00e1rgyak le\u00edr\u00e1s\u00e1nak hossz\u00e1t ellen\u0151rzi; \u00e9s \u00e9rt\u00e9keli a k\u00e9pek licencst\u00e1tusz\u00e1t. Ezen \u00e9rt\u00e9kel\u00e9sek alapj\u00e1n egy mennyis\u00e9gi pontsz\u00e1mot ad meg annak \u00e9rdek\u00e9ben, hogy nagyj\u00e1b\u00f3l m\u00e9rni tudjuk egy m\u0171t\u00e1rgy metaadatainak a teljess\u00e9g\u00e9t a min\u0151s\u00e9gi k\u00f6zz\u00e9t\u00e9telhez.",
        "plausi_explica": "Ellen\u0151rz\u00e9s sor\u00e1n a t\u00e1rgyak esem\u00e9nyeit (k\u00e9sz\u00edt\u00e9s, felhaszn\u00e1l\u00e1s stb.) vizsg\u00e1ljuk logikai \u00f6sszef\u00fcgg\u00e9s\u00fck szempontj\u00e1b\u00f3l a megadott id\u0151pontok \u00e9s szerepl\u0151k alapj\u00e1n. P\u00e9ld\u00e1ul egy 1950-ben gy\u00e1rtott ker\u00e9kp\u00e1r nem lehetett haszn\u00e1latban 1870-ben. Hasonl\u00f3k\u00e9ppen, egy f\u00e9nyk\u00e9p, amelyen Ice-T (sz\u00fcletett 1958) szerepel, nem k\u00e9sz\u00fclhetett 1920-ban.",
        "plausi_explica_2": "Ha a t\u00e1rgyn\u00e1l hasonl\u00f3 logikai ellentmond\u00e1s vagy elt\u00e9r\u00e9s ker\u00fcl felismer\u00e9sre az egyes esem\u00e9nyek k\u00f6z\u00f6tt, figyelmeztet\u00e9s jelenik meg.",
        "plausi_legal_explica": "Az ellen\u0151rz\u00e9s c\u00e9lja, hogy a t\u00e1rgyhoz felt\u00f6lt\u00f6tt k\u00e9pek licencel\u00e9si \u00e1llapot\u00e1val kapcsolatos nyilv\u00e1nval\u00f3 probl\u00e9m\u00e1kat azonos\u00edtsa \u00e9s jelezze. Ennek \u00e9rdek\u00e9ben a r\u00f6gz\u00edtett alkot\u00f3k \u00e9letrajzi adatait hat\u00e1rozza meg \u2013 ak\u00e1r k\u00f6zvetlen\u00fcl a megadott adatokb\u00f3l, olyan k\u00f6zponti adatb\u00e1zisokra hivatkozva, mint p\u00e9ld\u00e1ul a Library of Congress Subject Headings, a Wikidata vagy a N\u00e9met Nemzeti K\u00f6nyvt\u00e1r Gemeinsame Normdatei rendszere.",
        "plausi_legal_explica_2": "Az ellen\u0151rz\u00e9s azon a felt\u00e9telez\u00e9sen alapul, hogy a m\u00fazeumi t\u00e1rgyakr\u00f3l k\u00e9sz\u00fclt k\u00e9pek dokument\u00e1ci\u00f3s c\u00e9lt szolg\u00e1lnak \u2013 vagyis sok joghat\u00f3s\u00e1gban (p\u00e9ld\u00e1ul az EU-ban) maguk a k\u00e9pek nem r\u00e9szes\u00fclnek szerz\u0151i jogi v\u00e9delemben. Ennek megfelel\u0151en val\u00f3sz\u00edn\u0171s\u00edthet\u0151, hogy azoknak a t\u00e1rgyaknak a k\u00e9pei, amelyek alkot\u00f3ja t\u00f6bb mint 100 \u00e9ve elhunyt, k\u00f6zkincsnek min\u0151s\u00fclnek (itt a leghosszabb id\u0151tartamot vessz\u00fck figyelembe, amelyet b\u00e1rmely orsz\u00e1g egy m\u0171 szerz\u0151i jogi v\u00e9delm\u00e9re alkalmaz). Ha ett\u0151l elt\u00e9r\u0151 licencst\u00e1tusz szerepel, figyelmeztet\u00e9s jelenik meg.\r\n\r\nHasonl\u00f3k\u00e9ppen, figyelmeztet\u00e9s jelenik meg akkor is, ha olyan alkot\u00f3k \u00e1ltal l\u00e9trehozott t\u00e1rgyakr\u00f3l k\u00e9sz\u00fclt k\u00e9peket, akik m\u00e9g \u00e9lnek, vagy az elm\u00falt 50 \u00e9vben hunytak el (a Berni Egyezm\u00e9ny alapj\u00e1n), nem korl\u00e1toz\u00f3 licenccel l\u00e1ttak el.\r\n\r\nEzek az ellen\u0151rz\u00e9sek term\u00e9szetesen csak egy durva k\u00f6zel\u00edt\u00e9st adnak \u2013 a jogszab\u00e1lyok bonyolultak \u00e9s sokf\u00e9l\u00e9k, ahogyan az objektumadatok is. \u00d6sszess\u00e9g\u00e9ben azonban rem\u00e9lhet\u0151, hogy seg\u00edtenek az ism\u00e9tl\u0151d\u0151 probl\u00e9m\u00e1k felismer\u00e9s\u00e9ben, mik\u00f6zben nem gener\u00e1lnak t\u00fal sok t\u00e9ves figyelmeztet\u00e9st.",
        "citation": "Hivatkzo\u00e1s",
        "puqi_score": "PuQI \u00e9rt\u00e9k",
        "results": "Tal\u00e1latok",
        "objects_identified": "[placeholder_for_count] objects identified",
        "check_passed": "Check passed",
        "warning": "Figyelmeztet\u00e9s",
        "status": "St\u00e1tusz",
        "plausibility_warnings": "Plauzabilit\u00e1s: Figyelmeztet\u00e9sek",
        "plausibility_warnings_licenses": "Plausibility Check for Image Licenses: Warnings",
        "puqi_notices": "PuQI \u00fczenetek",
        "types_of_evaluations": "Types of Evaluations",
        "see": "See",
        "step": "Step",
        "select_import_format": "Select an import format",
        "upload_a_file": "Upload a file",
        "select_file_for_upload": "Select a file for upload",
        "alt_paste_text": "Or Paste the Object Record in Plain Text",
        "text": "Sz\u00f6veg",
        "submit": "Submit",
        "news": "News",
        "click_read_more": "Click to read more",
        "try_it_out": "Try it out",
        "intro_text": "Since the 1980s, more and more museums have started managing their object data digitally. Where inventory cards oftentimes only covered the most rudimentary information systematically, digital record-keeping allows for a much more detailled description of the objects without any of the space limitations inherent to the medium of the inventory card. Detailed information that had often only been written down unsystematically in catalogues or research articles can now be stored and searched digitally alongside the rudimentary object data in a database. Simultaneously, an increasing number of museums has started to publish their collections in publicly accessible databases, often in collaboration with other museums, which have entirely different collections.\r\n\r\nA coverage of the collections that is at the same time systematic and detailled has thus only really been possible due to digitization. The increasingly close link between inventorization and publication of the object data on the other hand makes data quality more relevant than ever.\r\n\r\nmuseum-digital has helped museums and related institutions in collaboratively managing and publishing their collections online since 2009. In this context, a number of tools were written to measure and improve the quality of collection data.\r\n\r\nmuseum-digital:qa allows the (re-)use of these tools by users and software beyond museum-digital. They may be used directly via a web interface or via an API, which also allows for the simple embedding of the quality assessment tools into other collection management systems, which often do not feature comparable tools as of yet.",
        "summary": "Summary",
        "tech_background_hl": "Technical background",
        "faq": "Frequently Asked Questions",
        "tech_background_summary": "museum-digital:qa resuses those components of museum-digital's improt tool, which cover the tasks of parsing different input formats and converting them into a uniform format for simple processing. It thus supports reading both well-established open standards for data exchange in the cultural heritage sector as well as the specific export formats of a number of collection management systems to establish a platform for the processing of museum data from a variety of sources. The data thus read are then checked for their completeness and coherence.",
        "currently_offline_msg": "You are currently offline. Evaluation happens on the server. Please try to reconnect your network first.",
        "filesize_too_big": "The file is too big! The maximum allowed size of uploaded files is [placeholder] byte.",
        "quality_assessment_tools": "Quality assessment tools",
        "api": "API",
        "outlook": "Outlook",
        "faq_q_why_is_my_cms_not_supported": "Why are exports from my CMS not supported?",
        "faq_a_why_is_my_cms_not_supported": "As described in the section \"technical background\", not every collection management system offers export formats uniform across the different institutions using it. Besides the general open standards for museum-digital:qa can however only reasonably support those export formats that are not specific to a single institution.\r\n\r\nThe lack of a consistent export format often stems from the customizability of the underlying database structure as opposed to a superficial customizability of the interface - where the database structure is fully customized towards the use case of a museum, custom exports need to be written as well - which in turn means additional cost and effort.\r\n\r\nIf your software however supports a uniform export format across institutions, which is not yet usable with museum-digital:qa, we would be most interested in supporting it in the future as well. In such cases, please send a mail - ideally along with some sample exports - to quality@museum-digital.de.",
        "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.",
        "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",
        "count_new_to_vocabs": "Counters for new vocabulary entries at museum-digital",
        "count_new_to_vocabs_short": "Count: new vocabulary entries",
        "count_new_to_vocabs_explica_1": "museum-digital:quality strings together the parsing of input data of different formats from museum-digital's import tool with different checks. That also means that all data that can be checked using museum-digital:quality could be imported to museum-digital as well.\r\n\r\nActually importing the data however regularly also entails adding missing entries to museum-digital's controlled vocabularies for actors, places, times, and tags, which need to be cleaned and enriched in the aftermath of the import. Using this check, the number of such newly added entries can be counted.",
        "samples": "Samples",
        "select_activity": "What would you like to do with the data?",
        "evaluate": "Evaluate",
        "convert_to_xml": "Convert to XML",
        "select_conversion_target_format": "Select the target format for conversion",
        "other_features": "Other features",
        "convert_to_xml_explica": "museum-digital:qa can leverage the XSL transformations written for musdb to convert any imported data to those XML formats musdb can export to. Next to the well-established exchange standard LIDO this includes EODEM, a recent extension to LIDO meant to simplify data exchange for registrars specifically in the case of loans between museums."
    }
}