Source strings

1,670 Strings
100%
Browse Translate
59,661 Words
100%
394,750 Characters
100%
This translation is being used as source strings within this component.

Strings status

Strings Words Characters
1,670 59,661 394,750
All strings Browse Translate Zen
1,670 59,661 394,750
Read-only strings Browse Translate Zen
19 3,066 19,657
Strings with any failing checks Browse Translate Zen
16 2,526 16,219
Failing check: Unpluralised Browse Translate Zen
3 540 3,438
Failing check: Ellipsis Browse Translate Zen

Summary

Project website ds-wizard.org
Translation license MIT License
Translation process
  • Translations can be made directly.
  • Translation suggestions can be made.
  • Any authenticated user can contribute.
  • The translation uses bilingual files.
Source code repository git@github.com:ds-wizard/dsw-root-locales.git
Repository branch main
Last remote commit Update POT from dsw:root:2.8.1 50efbd9
User avatar marek.suchanek authored 09/12/2026
Last commit in Weblate Translated using Weblate (Chinese (Traditional Han script)) e70d05c
User avatar wanally authored 09/22/2026
Weblate repository https://localize.ds-wizard.org/git/knowledge-models/common-dsw-knowledge-model/
File mask locales/*/messages.po
Translation file Download messages.pot
Last change Sept. 12, 2026, 6:30 a.m.
Last change made by None
Language English
Language code en
Text direction Left to right
Case sensitivity Case-sensitive
Number of speakers 1,728,473,503
Number of plurals 2
Plural type One/other
Plurals Singular 1
Plural 0, 2, 3, 4, 5, 6, 7, 8, 9, 10, …
Plural formula n != 1
09/22/2026

String statistics

Strings percent Hosted strings Words percent Hosted words Characters percent Hosted characters
Total 1,670 59,661 394,750
Translated 100% 1,670 100% 59,661 100% 394,750
Needs editing 0% 0 0% 0 0% 0
Read-only 100% 1,670 100% 59,661 100% 394,750
Failing checks 1% 19 5% 3,066 4% 19,657
Strings with suggestions 0% 0 0% 0 0% 0
Untranslated strings 0% 0 0% 0 0% 0
Last 12 months Previous

Activity in last 12 months

0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 1,467 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes
SepOctNovDecJanFebMarAprMayJunJulAug

Quick numbers

59,661
Hosted words
1,670
Hosted strings
100%
Translated
0
Contributors
and previous 30 days

Trends of last 30 days

+65%
Hosted words
+100%
+12%
Hosted strings
+100%
—
Translated
+100%
—
Contributors
—
User avatar None

Resource updated
The “messages.pot” file was changed. 09/12/2026
User avatar None

String added in the repository
## What's up?

Workflows, especially composite ones are inherently unstable unless otherwise proven. One way to verify that a workflow is stable, especially if it is composed of multiple independently developed and operating components, is to run it on a regular basis on standard reference and calibration data sets. If results on the reference calibration set are different, apparently one of the components of the workflow is not functioning properly or has been changed. The change may actually be an improvement from the point of the continent provider, but in many cases, updates and new versions are released without proper pre-notification to all users (if these are known and tracked in the first place).

So, even if components of a third party workflow are improved they may still cause irreparable damage to your research by introducing unnoticed or otherwise irreparable aberrations or even damage to data. So especially when a remote workflow or service has not been used for a while in your local setting you must carefully check and verify that the results of the workflow on your reference data set are identical to the last time you ran the workflow.

## Do

- Maintain stable reference and calibration data sets for each workflow operational in your research setting.
- Run these at a regular basis in order to prevent that you only find out that the workflow has been changed at the moment you need it urgently and your raw data or measurements may suffer.
- Contact all providers of workflows and make sure they know you are using their tools and ask for notification of changes or errors.

## Don't

- Ever re-run a workflow on new data (especially when the results 'add to accumulating evidence' just assuming that the workflow (even if claimed to be stable) is indeed stable.
- Accumulate evidence and data in collections that were generated at different time points with potentially changing workflows that have corrupted or otherwise rendered subsets of your collection 'outliers' that may completely mess up the collection.

---

[**Data Stewardship for Open Science: Chapter 4.2.4**](https://www.routledge.com/Data-Stewardship-for-Discovery-A-Practical-Guide-for-Data-Experts/Mons/p/book/9781498753173) with kind permission of [CRC Press](https://taylorandfrancis.com/)
## What's up?

Workflows, especially composite ones are inherently unstable unless otherwise proven. One way to verify that a workflow is stable, especially if it is composed of multiple independently developed and operating components, is to run it on a regular basis on standard reference and calibration data sets. If results on the reference calibration set are different, apparently one of the components of the workflow is not functioning properly or has been changed. The change may actually be an improvement from the point of the continent provider, but in many cases, updates and new versions are released without proper pre-notification to all users (if these are known and tracked in the first place).

So, even if components of a third party workflow are improved they may still cause irreparable damage to your research by introducing unnoticed or otherwise irreparable aberrations or even damage to data. So especially when a remote workflow or service has not been used for a while in your local setting you must carefully check and verify that the results of the workflow on your reference data set are identical to the last time you ran the workflow.

## Do

- Maintain stable reference and calibration data sets for each workflow operational in your research setting.
- Run these at a regular basis in order to prevent that you only find out that the workflow has been changed at the moment you need it urgently and your raw data or measurements may suffer.
- Contact all providers of workflows and make sure they know you are using their tools and ask for notification of changes or errors.

## Don't

- Ever re-run a workflow on new data (especially when the results 'add to accumulating evidence' just assuming that the workflow (even if claimed to be stable) is indeed stable.
- Accumulate evidence and data in collections that were generated at different time points with potentially changing workflows that have corrupted or otherwise rendered subsets of your collection 'outliers' that may completely mess up the collection.

---

[**Data Stewardship for Open Science: Chapter 4.2.4**](https://www.routledge.com/Data-Stewardship-for-Discovery-A-Practical-Guide-for-Data-Experts/Mons/p/book/9781498753173) with kind permission of [CRC Press](https://taylorandfrancis.com/)
09/12/2026
User avatar None

String added in the repository
Verify repeatedly on the same data
Verify repeatedly on the same data
09/12/2026
User avatar None

String added in the repository
## What's up?

A workflow run without supervision is a grave risk to your project. When you run a workflow, you need to have a system in place to monitor progress and potential errors. Not all workflows and services have professional and built-in error messaging, restore possibilities etc. It is a disaster if you only find out that the workflow has been stalled (a web service component was off-line for instance) after a long time and after potentially irreparable damage to the data has been done. Obviously, always also keep a backup of the original data that were entered into the workflow as some workflows may discard interim files, which may make rescue of data immediately after workflow-internal error only possible by starting all over again with a repaired workflow and the original data.

## Do

- Monitor every workflow that is running on a continuous basis (or install/develop machine-monitoring'
- Keep a copy of the original input to enable restarting of the workflow at any time with the original input.
- Make sure you record every step of the workflow (completed successfully, error detected, component restarted etc.) in order to be able to trace the source of aberrations in outcome.
- If the input of the workflow is subject to change over time (for instance sample measurement where quality of sample or staining/labelling is subject to decay) take extra measure (run the supervised workflow with reference data before starting the real experiment.

## Don't

- Let any workflow run completely unsupervised and assume the output is correct and can be fed into the next step of processing or analysis.
- Restart a workflow after a detected error without carefully recording what the error was and what was done to repair the process.
- Re-run workflows that work on input that may subject to change over time (and will therefore give different results when re-run even if the workflow did a perfect job).

---

[**Data Stewardship for Open Science: Chapter 4.3**](https://www.routledge.com/Data-Stewardship-for-Discovery-A-Practical-Guide-for-Data-Experts/Mons/p/book/9781498753173) with kind permission of [CRC Press](https://taylorandfrancis.com/)
## What's up?

A workflow run without supervision is a grave risk to your project. When you run a workflow, you need to have a system in place to monitor progress and potential errors. Not all workflows and services have professional and built-in error messaging, restore possibilities etc. It is a disaster if you only find out that the workflow has been stalled (a web service component was off-line for instance) after a long time and after potentially irreparable damage to the data has been done. Obviously, always also keep a backup of the original data that were entered into the workflow as some workflows may discard interim files, which may make rescue of data immediately after workflow-internal error only possible by starting all over again with a repaired workflow and the original data.

## Do

- Monitor every workflow that is running on a continuous basis (or install/develop machine-monitoring'
- Keep a copy of the original input to enable restarting of the workflow at any time with the original input.
- Make sure you record every step of the workflow (completed successfully, error detected, component restarted etc.) in order to be able to trace the source of aberrations in outcome.
- If the input of the workflow is subject to change over time (for instance sample measurement where quality of sample or staining/labelling is subject to decay) take extra measure (run the supervised workflow with reference data before starting the real experiment.

## Don't

- Let any workflow run completely unsupervised and assume the output is correct and can be fed into the next step of processing or analysis.
- Restart a workflow after a detected error without carefully recording what the error was and what was done to repair the process.
- Re-run workflows that work on input that may subject to change over time (and will therefore give different results when re-run even if the workflow did a perfect job).

---

[**Data Stewardship for Open Science: Chapter 4.3**](https://www.routledge.com/Data-Stewardship-for-Discovery-A-Practical-Guide-for-Data-Experts/Mons/p/book/9781498753173) with kind permission of [CRC Press](https://taylorandfrancis.com/)
09/12/2026
User avatar None

String added in the repository
Workflow running
Workflow running
09/12/2026
User avatar None

String added in the repository
## What's up?

In many cases end-to-end pipelines may exist for the type of data processing you need. However, it may also be true that you need only particular components of a workflow. When workflows are based on serialised components (for instance web services) that can be relatively independently deployed, it may be an option to use only part of an existing workflow. However, be aware of the stability issues related to web services. In case web services are maintained by academic groups, there may very well be issues related to proper documentation, versioning and support that can severely hamper your experimental procedures. If the reliability of the average web service is 80% (up-time, versioning etc.) and you need a sequence of 5 web services to run your workflow, do the math on how likely it is that the entire workflow will run smoothly. Therefore, if professional tools exist (even if they are proprietary and not Open Source) carefully study and discuss the balance between using Open Source software that you can adapt yourself, its professional support level (which may cost you regardless of the license situation of the software) and the use of commercial software (Open Source or Closed). There is obviously a tendency in academia to use Open Source software whenever possible, but this is not always adding to efficiency, just to 'perceived freedom to hack' and also sometimes based on a strong bias against 'commercial software' and the fear for 'vendor lock in'. These fears are not always unjustified but going for unprofessional 'hacks' just to save some money (in the short term) or based on your desire to be able to 'change and tweak' things yourself (or even worse, purely motivated by the desire to publish on something new *per se*) may not at all be the best servant for your research team. Laboratory analysts would be punished immediately if they crafted their test tubes themselves or made their reagents in a non GLP environment, so why would that be acceptable for data analysts? So the choice of workflow engine is as much a team choice (with your advise) as the choice to use reagents such as antibodies from a commercial (guaranteed) provider versus producing them in the lab by immunising mice. Questions to be answered in the process of choosing an existing workflow, engine or service include considerations about the ease of custom developments. For instance; can a workflow be edited collaboratively, can you reach out to and collaborate with the developers? Does it support the compute back ends you need?, does it offer standard tools for the administrative operations? What is the ease of adding new tools, does it support nesting of workflows? is it easy to use, also for non-computer experts, for instance does it have a running and easy GUI?

## Do

- Check the various workflow options and engines, not only for promised functionality but also for:
- Level of documentation, support, licensing and reliability.
- Keep in mind that your final responsibility is the quality of the processed data, not to make new algorithms.
- Get in direct contact with the workflow engine provider and follow training if necessary.
- Run the workflow, engine, pipeline on exemplar data first.
- Take the 'running' environment into account and check the sustainability of that environment (for instance Galaxy)
- check who in the team will have to operate the workflow (experimentalists and ICT people may prefern very different UI's)

## Don't

- Develop new workflows or workflow engines unless demonstrably unavoidable and consented by the team.
- Use unsupported tools or environments 'just because they are easy to access and OS'.
- Discard the idea to use commercial or otherwise proprietary workflows without careful consideration and discussion with the rest of the team, especially when your data are difficult to reproduce.
- Expect purely academically published and 'provided' workflows and web services to be 'up and running' all the time and consider an entire workflow as one unit, without inspecting all serial elements of it for reliability and usefulness.

---

[**Data Stewardship for Open Science: Chapter 4.2**](https://www.routledge.com/Data-Stewardship-for-Discovery-A-Practical-Guide-for-Data-Experts/Mons/p/book/9781498753173) with kind permission of [CRC Press](https://taylorandfrancis.com/)
## What's up?

In many cases end-to-end pipelines may exist for the type of data processing you need. However, it may also be true that you need only particular components of a workflow. When workflows are based on serialised components (for instance web services) that can be relatively independently deployed, it may be an option to use only part of an existing workflow. However, be aware of the stability issues related to web services. In case web services are maintained by academic groups, there may very well be issues related to proper documentation, versioning and support that can severely hamper your experimental procedures. If the reliability of the average web service is 80% (up-time, versioning etc.) and you need a sequence of 5 web services to run your workflow, do the math on how likely it is that the entire workflow will run smoothly. Therefore, if professional tools exist (even if they are proprietary and not Open Source) carefully study and discuss the balance between using Open Source software that you can adapt yourself, its professional support level (which may cost you regardless of the license situation of the software) and the use of commercial software (Open Source or Closed). There is obviously a tendency in academia to use Open Source software whenever possible, but this is not always adding to efficiency, just to 'perceived freedom to hack' and also sometimes based on a strong bias against 'commercial software' and the fear for 'vendor lock in'. These fears are not always unjustified but going for unprofessional 'hacks' just to save some money (in the short term) or based on your desire to be able to 'change and tweak' things yourself (or even worse, purely motivated by the desire to publish on something new *per se*) may not at all be the best servant for your research team. Laboratory analysts would be punished immediately if they crafted their test tubes themselves or made their reagents in a non GLP environment, so why would that be acceptable for data analysts? So the choice of workflow engine is as much a team choice (with your advise) as the choice to use reagents such as antibodies from a commercial (guaranteed) provider versus producing them in the lab by immunising mice. Questions to be answered in the process of choosing an existing workflow, engine or service include considerations about the ease of custom developments. For instance; can a workflow be edited collaboratively, can you reach out to and collaborate with the developers? Does it support the compute back ends you need?, does it offer standard tools for the administrative operations? What is the ease of adding new tools, does it support nesting of workflows? is it easy to use, also for non-computer experts, for instance does it have a running and easy GUI?

## Do

- Check the various workflow options and engines, not only for promised functionality but also for:
- Level of documentation, support, licensing and reliability.
- Keep in mind that your final responsibility is the quality of the processed data, not to make new algorithms.
- Get in direct contact with the workflow engine provider and follow training if necessary.
- Run the workflow, engine, pipeline on exemplar data first.
- Take the 'running' environment into account and check the sustainability of that environment (for instance Galaxy)
- check who in the team will have to operate the workflow (experimentalists and ICT people may prefern very different UI's)

## Don't

- Develop new workflows or workflow engines unless demonstrably unavoidable and consented by the team.
- Use unsupported tools or environments 'just because they are easy to access and OS'.
- Discard the idea to use commercial or otherwise proprietary workflows without careful consideration and discussion with the rest of the team, especially when your data are difficult to reproduce.
- Expect purely academically published and 'provided' workflows and web services to be 'up and running' all the time and consider an entire workflow as one unit, without inspecting all serial elements of it for reliability and usefulness.

---

[**Data Stewardship for Open Science: Chapter 4.2**](https://www.routledge.com/Data-Stewardship-for-Discovery-A-Practical-Guide-for-Data-Experts/Mons/p/book/9781498753173) with kind permission of [CRC Press](https://taylorandfrancis.com/)
09/12/2026
User avatar None

String added in the repository
Choose the workflow engine
Choose the workflow engine
09/12/2026
User avatar None

String added in the repository
## What's up?

There are a lot of data capture procedures that are not strictly spoken 'instrumental output'. It is obvious that you can not walk with the researcher in the field that takes water or soil samples, be at the table of the pathologist that takes a tissue sample or the microscopist that makes sections, stains, embeds and preserves them, nor can you walk with each research assistant approaching people with questionnaires. However, careful consideration of how data capture procedures that have a strong non-standardised (human) component such as active questioning of subjects or surgical procedures may influence the ultimate data you will have to steward is a key task for a good data steward. Very much like machines may need to be calibrated at regular times and data may slightly vary based on how long ago that calibration took place, different students may cause different biases in the filing of questionnaires based on subtle signals they send to the interviewed person. Obviously, as with machines, the data steward cannot change that, but for instance, careful recording of who took what survey when and under which conditions is extremely important.

## Do

- 'Know your source': make sure that when data are generated in 'variable circumstances by non-standardizable agents (such as humans) you are aware of that and you have procedures in place to detect unintendedly introduced variance (and correct for it if possible).
- Discuss data-view based concerns with the research team and make sure that all data and sample collectors are optimally aware of the value of standard operating procedures but also of the need to record any abnormality encountered during the data capture procedure.
- Keep all records of the capture and pre-processing procedures even after data have been harmonized and normalized. This is not only for review and reproducibility purposes, but also to ensure that if unexpected trends are observed.

## Don't

- Consider the data or sample capture people and procedures 'none of your business'
- leave the considerations about variables in data capture procedures to the experimental team and (again) see yourself merely as the 'recipient of the data' when they come out of the experimental workflow.
- Consider any recorded data and metadata during the capture process as disposable at any later stage unless there is a very good argument to destroy them.

---

[**Data Stewardship for Open Science: Chapter 3.2.1**](https://www.routledge.com/Data-Stewardship-for-Discovery-A-Practical-Guide-for-Data-Experts/Mons/p/book/9781498753173) with kind permission of [CRC Press](https://taylorandfrancis.com/)
## What's up?

There are a lot of data capture procedures that are not strictly spoken 'instrumental output'. It is obvious that you can not walk with the researcher in the field that takes water or soil samples, be at the table of the pathologist that takes a tissue sample or the microscopist that makes sections, stains, embeds and preserves them, nor can you walk with each research assistant approaching people with questionnaires. However, careful consideration of how data capture procedures that have a strong non-standardised (human) component such as active questioning of subjects or surgical procedures may influence the ultimate data you will have to steward is a key task for a good data steward. Very much like machines may need to be calibrated at regular times and data may slightly vary based on how long ago that calibration took place, different students may cause different biases in the filing of questionnaires based on subtle signals they send to the interviewed person. Obviously, as with machines, the data steward cannot change that, but for instance, careful recording of who took what survey when and under which conditions is extremely important.

## Do

- 'Know your source': make sure that when data are generated in 'variable circumstances by non-standardizable agents (such as humans) you are aware of that and you have procedures in place to detect unintendedly introduced variance (and correct for it if possible).
- Discuss data-view based concerns with the research team and make sure that all data and sample collectors are optimally aware of the value of standard operating procedures but also of the need to record any abnormality encountered during the data capture procedure.
- Keep all records of the capture and pre-processing procedures even after data have been harmonized and normalized. This is not only for review and reproducibility purposes, but also to ensure that if unexpected trends are observed.

## Don't

- Consider the data or sample capture people and procedures 'none of your business'
- leave the considerations about variables in data capture procedures to the experimental team and (again) see yourself merely as the 'recipient of the data' when they come out of the experimental workflow.
- Consider any recorded data and metadata during the capture process as disposable at any later stage unless there is a very good argument to destroy them.

---

[**Data Stewardship for Open Science: Chapter 3.2.1**](https://www.routledge.com/Data-Stewardship-for-Discovery-A-Practical-Guide-for-Data-Experts/Mons/p/book/9781498753173) with kind permission of [CRC Press](https://taylorandfrancis.com/)
09/12/2026
User avatar None

String added in the repository
Do you have non-equipment data capture? (questionnaires, free text etc.)
Do you have non-equipment data capture? (questionnaires, free text etc.)
09/12/2026
User avatar None

String added in the repository
## What's up?

As argued before, the separation between data and 'software' (executable code) is close to blurred in data driven science. In many cases therefore, your experimental workspace will hold you *de novo* research data, OPEDAS and software packages that you use to process and analyse the data.

This means that 'active data' like executable code may influence the workspace in a different way from 'static' data. Software packages that are Open Source and not properly supported my seriously disrupt the workspace and cause all kinds of troubles. Also, software used in the workspace may carry with it certain licenses that render the processed data unusable for the purposes you had in mind with them. First of all, it is therefore critically important that you never mix the loaded data for processing and analysis as they are mounted in the active workspace counting as 'one of the copies' or even a back up. The principle attitude must be that data that are actively used in the workspace will at some point be corrupted or lost due to unforeseen events. But also software itself (when active) may become corrupted and may need to be restored from another source in order to re-run processes and analytics.

## Do

- Keep 'static' and safe back ups of both data and software that is mounted in the workspace
- Conduct regular integrity checks on the data elements in the workspace to prevent unexpected outcomes due to corruption of data, software or processes. unnoticed events may seriously slow down proper experimentation, analytics and interpretation of data and you as a steward cannot expect the rest of the research team to notice.
- Make sure that versions of the software and workflows (including plug-ins like vocabulary services) do not change unexpectedly (academics are notorious in changing things without notifying potential external users).
- Treat your workspace as a 'stand alone' and time delimited environment where you run stable data and processes (so for instance no 'remote mounting of thesauri of web services you do not control).
- Keep very careful records of versions and potential issues of all elements (data as well as software) that were used to run a particular process at a particular time. Basically treat each 'run' of a workflow system as a 'batch' with a unique identifier and rich provenance.
- Make sure you can always restore safely and quickly, an 'identical' workspace (although always a new 'batch' identifier will be needed) from the archive.

## Don't

- Ever regard the active workspace, its data and its software as 'another backup' of your data.
- Produce and deliver data from the workspace back to the team without carefully monitored and described 'provenance' and a 'batch' identifier.

---

[**Data Stewardship for Open Science: Chapter 2.6**](https://www.routledge.com/Data-Stewardship-for-Discovery-A-Practical-Guide-for-Data-Experts/Mons/p/book/9781498753173) with kind permission of [CRC Press](https://taylorandfrancis.com/)
## What's up?

As argued before, the separation between data and 'software' (executable code) is close to blurred in data driven science. In many cases therefore, your experimental workspace will hold you *de novo* research data, OPEDAS and software packages that you use to process and analyse the data.

This means that 'active data' like executable code may influence the workspace in a different way from 'static' data. Software packages that are Open Source and not properly supported my seriously disrupt the workspace and cause all kinds of troubles. Also, software used in the workspace may carry with it certain licenses that render the processed data unusable for the purposes you had in mind with them. First of all, it is therefore critically important that you never mix the loaded data for processing and analysis as they are mounted in the active workspace counting as 'one of the copies' or even a back up. The principle attitude must be that data that are actively used in the workspace will at some point be corrupted or lost due to unforeseen events. But also software itself (when active) may become corrupted and may need to be restored from another source in order to re-run processes and analytics.

## Do

- Keep 'static' and safe back ups of both data and software that is mounted in the workspace
- Conduct regular integrity checks on the data elements in the workspace to prevent unexpected outcomes due to corruption of data, software or processes. unnoticed events may seriously slow down proper experimentation, analytics and interpretation of data and you as a steward cannot expect the rest of the research team to notice.
- Make sure that versions of the software and workflows (including plug-ins like vocabulary services) do not change unexpectedly (academics are notorious in changing things without notifying potential external users).
- Treat your workspace as a 'stand alone' and time delimited environment where you run stable data and processes (so for instance no 'remote mounting of thesauri of web services you do not control).
- Keep very careful records of versions and potential issues of all elements (data as well as software) that were used to run a particular process at a particular time. Basically treat each 'run' of a workflow system as a 'batch' with a unique identifier and rich provenance.
- Make sure you can always restore safely and quickly, an 'identical' workspace (although always a new 'batch' identifier will be needed) from the archive.

## Don't

- Ever regard the active workspace, its data and its software as 'another backup' of your data.
- Produce and deliver data from the workspace back to the team without carefully monitored and described 'provenance' and a 'batch' identifier.

---

[**Data Stewardship for Open Science: Chapter 2.6**](https://www.routledge.com/Data-Stewardship-for-Discovery-A-Practical-Guide-for-Data-Experts/Mons/p/book/9781498753173) with kind permission of [CRC Press](https://taylorandfrancis.com/)
09/12/2026
Browse all translation changes