# 1. Introduction
Collecting voice data for low-resource languages: a playbook on how to engage communities and build voice datasets for language AI solutions
### Welcome to the playbook for voice data collection for low-resource languages!
This playbook will help you to plan and manage projects to collect [voice data](#user-content-fn-1)[^1] for [low-resource languages](#user-content-fn-2)[^2]. It is aimed at both new and experienced teams and covers the full process, from setting up the project to publishing your dataset[^3]. We draw on CLEAR Global’s experience with our data collection platform “[TWB Voice](#user-content-fn-4)[^4]”. The playbook also covers aspects of data collection that apply to organizations and communities who want to collect voice data through other platforms or initiatives.
Around four billion people lack access to voice technologies like speech recognition and conversational AI. This is because their languages don’t have the data available to build these tools. This playbook aims to help address this gap by outlining the key steps, challenges, and best practices for collecting voice data in low-resource languages in an effective and ethical way.
In this chapter, we introduce TWB Voice, CLEAR Global’s platform for collecting voice data. We refer to TWB Voice throughout this playbook. We also explain key terms and concepts in [voice technology](#user-content-fn-5)[^5], and show you how to use the playbook.
| **How CLEAR Global can help** |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
CLEAR Global’s mission is to help people get vital information and be heard, whatever language they speak. We help our partner organizations to listen to the communities they work with and communicate with them effectively.
Our tech-focused work helps organizations to find use cases where language technology could help users get more actively engaged and scale up communications efforts. We develop language AI solutions such as chatbots, machine translation, and speech solutions for low-resource languages. These are languages that don’t have enough data to create such language solutions. We also work with partners to help them collect voice data to build the resources for these technologies.
CLEAR Global’s user experience (UX) team can help with user research and UX design, and advise on human-centered design to tech interventions.
Our Language Services team can translate messages and documents into local languages, help with audio translations and pictures, train staff and volunteers, and give advice on two-way communication. We also work with partners to field test materials and make them easier to understand so they will have more impact. This work is backed up by research and language mapping to assess the communication needs of target populations.
For more information, go to our website or contact us at .
|
[^1]: **Voice data:** Audio recordings of human speech. These recordings capture the acoustic features of spoken language, such as pronunciation, speaking patterns, and rhythm.
[^2]: **Low-resource language:** A language that has limited written or recorded materials and is rarely found in digital tools, data, or technology. This means that technologies like speech recognition or machine translation are not available for the language and are difficult to build. This may be due to a lack of written content, digital resources (like websites or videos), or support from organizations that develop language technology.
[^3]: **Dataset:** A collection of information that has been organized for use. A **voice dataset** is a collection of voice recordings (paired with transcription) with additional information (metadata) such as gender, age of the person recording to give more information on how the data set is constructed and to avoid bias. It is for use in research and for training or improving voice models.
[^4]: **TWB Voice:** A platform for collecting voice data. It was developed by CLEAR Global, who also own it. Users can make voice recordings to help with active data collection projects in TWB Voice by [signing up to the TWB Community](https://translatorswithoutborders.org/join-the-twb-community/). The main goal of TWB Voice is to help to develop voice technology for speakers of marginalized languages. For example, by creating the voice datasets that are needed to build language models for TTS and ASR.
[^5]: **Voice technology:** Language technology that processes or generates spoken words.
# 1.1 How to use this playbook
### Who this playbook is for
This playbook is for anyone who is planning to collect [voice data](#user-content-fn-1)[^1], is already collecting it, or wants to find out how to do it. It contains practical guidance and lessons for users, including:
* **organizations who manage projects to collect voice data** in various languages and sectors
* **linguists and** [**community members**](#user-content-fn-2)[^2] who are helping to collect voice data
* **humanitarian and development teams** who want to use voice technologies to improve access to services
* **researchers and practitioners** who are working on inclusive voice-enabled tools or testing them in real-world settings
It may also be useful for funders and donors. It will help them to understand more about projects to collect voice data, and what ethical and scalable efforts involve.
At the start of each chapter, look for this icon: \
It marks a quick-reference box that tells you who the chapter is for and what level of expertise you need to read it. Here is the example for this chapter:
{% hint style="info" %}
You don’t need to be a technical expert for this section of the playbook. It’s a good starting point for anyone new to the playbook, whether you want to read a specific section or the whole guide.
{% endhint %}
### Different ways to use this playbook
In each section of this playbook, you will find information, steps you can take, and practical examples from the [TWB Voice](#user-content-fn-3)[^3] platform. These will guide you through the process of collecting voice data. Here are some ways you can use this playbook:
* **Step-by-step learning:** If you are new to [voice data collection](#user-content-fn-4)[^4], start with the early chapters. This will help you to understand the key concepts and stages of a project. You can follow the chapters in order or jump to sections that match your needs.
* **Real-world examples:** Case studies from work completed by both CLEAR Global and partners with TWB Voice provide practical lessons that you can apply to your own projects.
* **Quick reference:** Already collecting data? Use the playbook to look up specific topics when you face problems. For example, how to store and share data.
* **Learn together:** Share ideas, ask questions, and work with partners, experts, and our team.
### Share your feedback!
Send us an [email](mailto:tech@clearglobal.org) or fill out this [feedback form](https://docs.google.com/forms/d/e/1FAIpQLSc9vpLQuoVlr31FCRsAMT5-fJrGnwsN4VhN1Vd2dTNAvoEb7A/viewform?usp=header)! We would love to hear from you to improve this playbook.
[^1]: **Voice data:** Audio recordings of human speech, usually paired with a transcription. These recordings capture the acoustic features of spoken language, such as pronunciation, speaking patterns, and rhythm.
[^2]: **Community members:** People at the center of a project who contribute by recording and validating data. In this context, community refers to their shared interest in contributing to data collection and the languages they speak. Community members are well positioned to provide feedback on linguistic aspects and offer input on the project's direction and needs.
[^3]: **TWB Voice:** A platform for collecting voice data. It was developed by CLEAR Global, who also own it. Users can make voice recordings to help with active data collection projects in TWB Voice by [signing up to the TWB Community](https://translatorswithoutborders.org/join-the-twb-community/). The main goal of TWB Voice is to help to develop voice technology for speakers of marginalized languages. For example, by creating the voice datasets that are needed to build language models for TTS and ASR.
[^4]: **Voice data collection:** Gathering recordings of speech with their transcriptions in a systematic and ethical way. Also involves collecting demographic data (age, gender, accent) and for Automatic Speech Recognition should include a range of speakers. The voice data is used in research and for training or developing voice language models.
# 1.2 Chapter overviews
Click on any chapter title to jump to the chapter.
We explain what voice data is and why some languages don’t have functional voice technologies. We also look at the difference between read speech and spontaneous speech.
In this chapter, you will learn to identify and create prompts for voice recording. We explain how to find content sources for your language and domain. We also look at licensing and show you how to process text using automated and manual methods, and how to write prompts that elicit natural speech.
We explain how to record clear and natural voice data. We also show you how to check your recordings consistently (validation) and use quality control based on different roles.
We explain how to find the right people to work on a voice data project, onboard them effectively, and sustain their participation. We also cover ethical ways of motivating people and explain how to use feedback to keep them engaged.
We explain how CLEAR Global manages the collection of voice data. We also look at the steps it takes to make sure users know how CLEAR Global uses their data and what their rights are so they have control of their data.
We explain how to prepare and publish speech datasets, how to understand different types of licensing and access controls, how to manage data rights and community control, and how to work with pre-trained speech AI models.
We share detailed case studies of specific voice data collection projects delivered through TWB Voice by CLEAR Global and partners, highlighting the approaches used, what was learned, and what others can take from these experiences.
# 1.3 TWB Voice: CLEAR Global’s platform for voice data collection
TWB Voice is a platform for collecting [voice data](#user-content-fn-1)[^1]. It was set up by CLEAR Global in 2025 to collect and validate voice recordings from many contributors. These recordings help build voice technologies like [Automatic Speech Recognition (ASR](#user-content-fn-2)[^2]) and [Text-to-Speech (TTS)](#user-content-fn-3)[^3] for [low-resource languages](#user-content-fn-4)[^4].
You can access TWB Voice at [twbvoice.org](http://twbvoice.org). You will need to be a member of the Translators without Borders Community or sign up for an account. You can contribute to active TWB Voice projects in your language.
The aim of TWB Voice is to:
* support ethical, community-led voice data
* create high-quality, diverse datasets[^5] that will help to develop voice models[^6] that reflect how people really speak
* help people to access tools and information in their own language
On the platform, users can:
* record voice clips
* rate the voice recordings of others
* transcribe[^7] audio and rate the transcriptions of others
TWB Voice was built on more than 10 years of experience working with the Translators without Borders Community. This is a global network of 100,000+ volunteer linguists. TWB Voice helps this community to contribute their voices to aid the development of [voice technology](#user-content-fn-8)[^8] in their own languages.
| **Interested in working with us or finding out more about TWB Voice?** |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
We are looking for partners and voice data contributors to help TWB Voice to grow. We want to add more languages and improve the platform.
Get in touch to find out how we can work together.
|
###
### Data collection pilot in Hausa, Kanuri, and Shuwa Arabic
In TWB Voice’s first data collection pilot delivered in 2025, we collected conversational audio in Hausa, Kanuri, and Shuwa Arabic. CLEAR Global was already working with linguists and local partners in northeastern Nigeria to provide language services, do research, and develop [language technology](#user-content-fn-9)[^9]. The pilot aimed to create 50–100 hours of speech data per language. In practice, we collected:
* \~68 hours of speech data in Hausa of which \~58 hours for Automatic Speech Recognition and 10 hours for Text-to-Speech
* \~62 hours of speech data in Kanuri of which \~52 hours for Automatic Speech Recognition and 10 hours for Text-to-Speech
* \~15 hours of speech data in Shuwa Arabic for Automatic Speech Recognition
This is available as an open-source dataset for Automatic Speech Recognition and as samples for Text-to-Speech.
CLEAR Global and partners also used this data to develop:
1. Automatic Speech Recognition models for Hausa and Kanuri
2. Text-to-Speech models for Hausa and Kanuri.
You can find the datasets and models published as part of this pilot in [this repository on CLEAR Global’s Hugging Face page](https://huggingface.co/collections/CLEAR-Global/twb-voice-10-688797ff02e04524a6f41edc).
This pilot informed the first iteration of this playbook and is an important case study that we refer to throughout.
### What we learned since the first TWB Voice pilot
Since the pilot, CLEAR Global and our partners have continued work on voice data collection. We have expanded the projects delivered through TWB Voice, building on our work in Kanuri and working on voice data collection projects with the TWB Community and partners in a further 10 languages. This work is ongoing.
This work has helped us build on the lessons from the first pilot and identify additional guidance that may be useful for people planning and delivering voice data collection projects. In September 2026, we updated the Playbook to reflect what we learned from these projects and to add content that we identified as useful to share through this work.
This update includes a new [Case studies](/9.-case-studies) chapter. This includes two case studies written by CIATECH Africa and the Utavu AI Foundation, sharing their experiences and insights from working on voice data collection initiatives through TWB Voice in Kanuri and Dholuo in 2026.
[^1]: **Voice data:** Audio recordings of human speech. These recordings capture the acoustic features of spoken language, such as pronunciation, speaking patterns, and rhythm.
[^2]: **Automatic Speech Recognition (ASR) or Speech-to-Text (STT):** ASR converts spoken language into text. It can be used in voice assistants and transcription services, for example. You may hear both terms, ASR and STT, and they are almost the same. But STT can be a semi-manual process, while ASR is fully automated. ASR is like a smart listener that turns spoken words into written text on your device. While it does create the text automatically, it often needs some human input to make sure everything is correct, it can make mistakes especially in languages that are less used in the digital space.
[^3]: **Text-to-Speech (TTS):** Technology that converts written text into spoken language. It can also generate audio speech. You can find TTS in accessibility tools like screen readers and in virtual assistants. It brings written texts to life through spoken words. If your phone reads out the messages you get, or an audiobook tells you your favorite story, this is because of TTS technology.
[^4]: **Low-resource language:** A language that has limited written or recorded materials and is rarely found in digital tools, data, or technology. This means that technologies like speech recognition or machine translation are not available for the language and are difficult to build. This may be due to a lack of written content, digital resources (like websites or videos), or support from organizations that develop language technology.
[^5]: **Dataset:** A collection of information that has been organized for use. A voice dataset is a collection of voice recordings (paired with transcription) with additional information (metadata) such as gender, age of the person recording to give more information on how the data set is constructed and to avoid bias. It is for use in research and for training or improving voice models.
[^6]: **Model:** A computer-based system that has made use of data to learn patterns. It can make predictions or generate language. In speech technology, models use voice data to learn to recognize speech (converting audio to text) or to create speech (converting text to audio).
[^7]: **Transcribe**: Converting spoken words into written text.
[^8]: **Voice technology:** Language technology that processes or generates spoken words.
[^9]: **Language Technology (LT):** Technologies that focus on human language, including both spoken and written language. They can process, understand, and generate language. Examples are the tools on your phone or computer that understand and generate words, like translation apps or voice assistants. They allow us to communicate and interact with our devices with language. When you record a message and the device transforms it into text, or your phone suggests the next word in a message, that’s because of language technology. It makes digital tools more accessible, interactive and sometimes more efficient.
# 1.4 Glossary of key terms
In this section, we explain the most common terms and concepts that we use in voice data collection and voice technology, to help you navigate and understand this playbook.
**Artificial Intelligence (AI):** Artificial Intelligence (AI) refers to computer systems that can do tasks that normally require the intelligence of a human. Simply put: AI allows computers to do things that usually humans can do.
**Automatic Speech Recognition (ASR) or Speech-to-Text (STT):** ASR converts spoken language into text. It can be used in voice assistants and transcription services, for example. You may hear both terms, ASR and STT, and they are almost the same. But STT can be a semi-manual process, while ASR is fully automated. ASR is like a smart listener that turns spoken words into written text on your device. While it does create the text automatically, it often needs some human input to make sure everything is correct, it can make mistakes especially in languages that are less used in the digital space.
**Community members:** People at the center of a project who contribute by recording and validating data. In this context, community refers to their shared interest in contributing to data collection and the languages they speak. Community members are well positioned to provide feedback on linguistic aspects and offer input on the project's direction and needs.
**Consent form:** A document that voice contributors are presented with before they start recording. It explains how their data will be collected and used. If they agree to the terms and sign the form, they can begin contributing. The consent form helps ensure that contributors understand any risks, know their rights, and can make an informed choice about sharing their voice data.
**Contributor profiles:** Categories of people who are suitable for making recordings when you are collecting voice data. A category may be based on native language, bilingual ability or level of linguistic expertise.
**Corpus:** A collection of text or speech data that you can use to train language technology models.
**Creative Commons (CC) licenses:** A set of standard copyright licenses that let the creator of a piece of work choose which rights they want to keep and which they will give up.
**Data controller:** An individual or organization that is responsible for processing personal data. They decide why and how they will process the data. The General Data Protection Regulation states that data controllers have to make sure that data processing is lawful, transparent, and secure. They also have to respect the rights of the people whose data they process.
**Data incentive:** This means giving internet data to certain contributors to motivate them but also to ensure contributors have the required data to share their voice recordings over the internet.
**Data segregation:** Storing different types of data in separate systems or datasets. This keeps clear boundaries between their various uses. And you can make sure only the right people can gain access to the data. This means you can respect the choices of people who have provided their data.
**Dataset:** A collection of information that has been organized for use. A voice dataset is a collection of voice recordings (paired with transcription) with additional information (metadata) such as gender, age of the person recording to give more information on how the data set is constructed and to avoid bias. It is for use in research and for training or improving voice models.
**Digital language divide:** When it comes to access to technology, there is a big gap between people who speak high-resource languages and those who speak low-resource languages. It means that many people cannot enjoy the benefits of digitalization.
**Domain:** The subject area, topic or setting in which we use language. Examples are healthcare, farming, or education. Each domain has its own special terms and language patterns.
**Spontaneous speech prompts:** Open-ended questions or instructions that result in natural, free speech.
**The General Data Protection Regulation (GDPR):** A European Union law that deals with personal data. It tells us how to collect, process, store, and share data. It makes sure people have control over their personal data. It also ensures that organizations handle such data in a transparent, secure, and lawful way.
**Hugging Face:** An online platform where researchers and developers share AI models, datasets, and applications.
**Language Leads (LLs):** Language experts with lots of experience. They can do spot checks to ensure quality and can give feedback.
**Language Technology (LT):** Technologies that focus on human language, including both spoken and written language. They can process, understand, and generate language. Examples are the tools on your phone or computer that understand and generate words, like translation apps or voice assistants. They allow us to communicate and interact with our devices with language. When you record a message and the device transforms it into text, or your phone suggests the next word in a message, that’s because of language technology. It makes digital tools more accessible, interactive and sometimes more efficient.
**Leaderboard:** A table view that displays the performance of all contributors and allows them to compare how well they are doing against others in real time.
**Low-resource language:** A language that has limited written or recorded materials and is rarely found in digital tools, data, or technology. This means that technologies like speech recognition or machine translation are not available for the language and are difficult to build. This may be due to a lack of written content, digital resources (like websites or videos), or support from organizations that develop language technology.
**Metadata:** Extra information that gives some background to a dataset or parts of a dataset. Examples are demographics of the speakers (age, gender, accent), recording conditions (microphone type, level of background noise), or language-related details (dialect, speed of speaking, emotional tone).
**Middle-resource language:** Languages with medium-sized populations of speakers or that are moderately important in economic terms. They may have more resources in the form of documents, online presence to support commercial speech technology, but still don’t have enough voice datasets or a wide enough range to build quality solutions.
**Model:** A computer-based system that has made use of data to learn patterns. It can make predictions or generate language. In speech technology, models use voice data to learn to recognize speech (converting audio to text) or to create speech (converting text to audio).
**Normalization:** Putting text in a standard format that is suitable for speech applications (for example, writing out numbers in words, no abbreviations).
**Open and Responsible AI License (OpenRAIL):** A licensing framework that allows wide use but also provides responsible guidelines for the use of AI.
**Optical Character Recognition (OCR):** Technology that converts pictures of written text (like scanned documents) into text that a computer can read. This makes it possible to take content from printed materials and process it digitally.
**Programmatically:** Accessing data through code and programming interfaces rather than by manually downloading it.
**Rating:** An individual quality assessment by a contributor. They either approve or reject a piece of language data (recording in the case of voice data) and base their rating on the pass/fail guidelines. Several ratings may be needed to decide whether this data has passed or failed for quality.
**Read prompt:** A sentence that contributors read aloud from a written prompt. These sentences will give you controlled samples of speech.
**Recognition program:** A system of rewards (points, certificates, or money) to motivate contributors and acknowledge the importance of their efforts.
**Spontaneous voice data:** Recordings of natural speech with no script. These will contain hesitations, restarts, varied speaking patterns, and everyday phrases. They sound more like the way people actually talk.
**Spot checking:** Random checking of recordings/ratings for quality to to make sure they are consistent.
**Target language:** The language(s) for which you are collecting the voice data.
**Test partition:** A separate portion of data that is used to find out how well a model is working.
**Text-to-Speech (TTS):** Technology that converts written text into spoken language. It can also generate audio speech. You can find TTS in accessibility tools like screen readers and in virtual assistants. It brings written texts to life through spoken words. If your phone reads out the messages you get, or an audiobook tells you your favorite story, this is because of TTS technology.
**Training:** The process of teaching a computer-based model to recognize patterns by showing it large amounts of data as examples.
**Transcribe:** Converting spoken words into written text.
**Translators without Borders (TWB):** A part of CLEAR Global, a non-profit organization that helps people to get information and have a voice, whatever language they speak.
**TWB Community:** A global community of over 100,000 linguists. They donate their time and skills to translate information for millions of people around the world. They help people to get the information they need and want.
**TWB Voice:** A platform for collecting voice data. It was developed by CLEAR Global, who also own it. Users can make voice recordings to help with active data collection projects in TWB Voice by [signing up to the TWB Community](https://translatorswithoutborders.org/join-the-twb-community/). The main goal of TWB Voice is to help to develop voice technology for speakers of marginalized languages. For example, by creating the voice datasets that are needed to build language models for TTS and ASR.
**Validation by rating:** Listening to audio recordings to check them against the set criteria. For example, exact match to a specific text, no pauses, and clear speech. The user may then decide that a recording is accepted, rejected, or needs further validation, if they have the right permissions.
**Voice data:** Audio recordings of human speech. These recordings capture the acoustic features of spoken language, such as pronunciation, speaking patterns, and rhythm.
**Voice data collection:** Gathering recordings of speech with their transcriptions in a systematic and ethical way. Also involves collecting demographic data (age, gender, accent) and for Automatic Speech Recognition should include a range of speakers. The voice data is used in research and for training or developing voice language models.
**Voice technology:** Language technology that processes or generates spoken words.
# 1.5 Acknowledgements
This playbook was first written during the first phase of a project to develop CLEAR Global’s platform for voice data collection, “[TWB Voice](#user-content-fn-1)[^1]”. The project also aimed to create the first voice datasets within this platform. The project was funded by the Patrick J. McGovern Foundation (PJMF). This created a foundation for work in TWB Voice, and since then, with further support from PJMF and through further partnerships, we have continued developing the platform and delivering voice data collection projects with the TWB Community and partners.
We would like to say thank you to the many people who helped with this document, both directly and indirectly, including:
* our many partners, who have shared their time, knowledge, and feedback with us over many projects and years of work in voice technology and data collection.
* the Translators without Borders Community, especially the community members who have contributed to projects in TWB Voice. They gave us feedback and insights into the unique aspects of each language, and the needs of users on the platform. This helped us a lot when developing TWB Voice and creating the datasets.
* CIATECH Africa and the Utavu AI Foundation, who worked with CLEAR Global to deliver voice data collection projects through TWB Voice and to co-design new features and improvements. Their feedback and insights helped us better understand the needs of partners delivering voice data collection work and make the platform more user-friendly.
* Jane Ruessmann, who helped us make the playbook clearer and more accessible through her thoughtful plain language edit of the content.
[^1]: **TWB Voice:** A platform for collecting voice data. It was developed by CLEAR Global, who also own it. Users can make voice recordings to help with active data collection projects in TWB Voice by [signing up to the TWB Community](https://translatorswithoutborders.org/join-the-twb-community/). The main goal of TWB Voice is to help to develop voice technology for speakers of marginalized languages. For example, by creating the voice datasets that are needed to build language models for TTS and ASR.
# 2. What is voice data?
#### Chapter 2 overview:
{% hint style="info" %}
You don’t need to be a technical expert for this chapter. It’s for anyone who wants to understand the basics of voice technology. It includes:
* an introduction to **voice data**—the basis for all speech technologies
* a look at the **main types of speech technology** (TTS and ASR), and why some languages don’t have voice technology support
* the difference between **read speech** and **spontaneous speech**.
{% endhint %}
[Voice data](#user-content-fn-1)[^1] consists of audio recordings of human speech, ideally paired with transcriptions of what the person said and relevant metadata[^2]. We need it to develop language technologies that can process, understand, or generate spoken language.
Each recording in a [voice data collection](#user-content-fn-3)[^3] "trains" machines to process human speech and teaches them to recognize or generate speech. We collect voice recordings and their transcriptions as examples that will help algorithms to build models[^4]. These models are computer-based systems that can recognize patterns in human speech. They analyze thousands or millions of speech samples to find patterns between speech sounds and words or phrases. Voice data that comes from a wide range of speakers helps the models to get better at recognizing or generating speech. They learn to do this for different accents, speaking styles, and acoustic settings.
[^1]: **Voice data:** Audio recordings of human speech. These recordings capture the acoustic features of spoken language, such as pronunciation, speaking patterns, and rhythm.
[^2]: **Metadata:** Extra information that gives some background to a dataset or parts of a dataset. Examples are demographics of the speakers (age, gender, accent), recording conditions (microphone type, level of background noise), or language-related details (dialect, speed of speaking, emotional tone).
[^3]: **Voice data collection:** Gathering recordings of speech with their transcriptions in a systematic and ethical way. Also involves collecting demographic data (age, gender, accent) and for Automatic Speech Recognition should include a range of speakers. The voice data is used in research and for training or developing voice language models.
[^4]: **Model:** A computer-based system that has made use of data to learn patterns. It can make predictions or generate language. In speech technology, models use voice data to learn to recognize speech (converting audio to text) or to create speech (converting text to audio).
# 2.1 Technologies that use voice data
### Text-to-Speech (TTS)
[Text-to-Speech systems](#user-content-fn-1)[^1] convert written text into synthesized speech. These systems analyze text and create audio that copies human speech patterns. Modern TTS systems can:
* generate speech with a style of speaking and rhythm that sounds natural
* adapt to different speaking styles, accents, and moods
* read out text in real time to help people with accessibility needs
* allow people to use apps and services that are controlled by voice
To develop high-quality TTS systems, you generally need clean, studio-quality voice recordings. These systems work best when trained on data from controlled settings. There should be very little background noise, the audio level should be consistent, and the speakers should be professionals. To create natural-sounding synthesized speech, you need someone with good pronunciation who speaks clearly and expresses themselves in a fitting way.
### Automatic Speech Recognition (ASR)
[Automatic Speech Recognition](#user-content-fn-2)[^2] systems, or speech-to-text, convert spoken language into written text. These systems:
* process audio recordings and identify elements of speech
* take spoken content and convert it into written text
* allow people to use voice assistants and interfaces that are controlled by voice
* allow automated transcription of meetings, interviews, and other spoken content
ASR systems work better when trained on voice data that is diverse and varied. It should include a wide range of speakers, accents, and settings. To be effective, ASR models[^3] need to be trained with data that reflects the full range of real-world speech. This should include different ages, genders, accents, speaking styles and acoustic settings (for example, in noisy traffic).
[^1]: **Text-to-Speech (TTS):** Technology that converts written text into spoken language. It can also generate audio speech. You can find TTS in accessibility tools like screen readers and in virtual assistants. It brings written texts to life through spoken words. If your phone reads out the messages you get, or an audiobook tells you your favorite story, this is because of TTS technology.
[^2]: **Automatic Speech Recognition (ASR) or Speech-to-Text (STT):** ASR converts spoken language into text. It can be used in voice assistants and transcription services, for example. You may hear both terms, ASR and STT, and they are almost the same. But STT can be a semi-manual process, while ASR is fully automated. ASR is like a smart listener that turns spoken words into written text on your device. While it does create the text automatically, it often needs some human input to make sure everything is correct, it can make mistakes especially in languages that are less used in the digital space.
[^3]: **Model:** A computer-based system that has made use of data to learn patterns. It can make predictions or generate language. In speech technology, models use voice data to learn to recognize speech (converting audio to text) or to create speech (converting text to audio).
# 2.2 Data imbalance & low-resource languages
There is a serious imbalance in the [voice data](#user-content-fn-1)[^1] available for different languages. This is a big problem for the development of speech technology:
High-resource languages
With languages like English, Mandarin, Spanish, and French, there are thousands of hours of voice data available. This results in very accurate speech technologies.
Mid-resource languages
With languages that have moderate populations of speakers or that are important in economic terms, there may be some commercial speech technology support. However, they still don’t have the amount of voice datasets that are available for high-resource languages. Examples include Czech, Hindi, Polish, Tamil, Thai and Swahili.
Low-resource languages
For most of the world's 7,000+ languages, there is very little or no voice data available to develop technology. This is true even though millions of people speak these languages across the world. Kannada, Sindhi, and Tajik, for example, are “under-resourced” languages. Gondi, Khasi, and Santhali are “no-resource” languages as there is almost no data available for them.
The result of this imbalance is a "[digital language divide](#user-content-fn-3)[^3]". Speakers of low-resource languages cannot make use of voice technologies. Many of the languages spoken in areas affected by disaster or conflict are low-resource languages.
Some of the results of this imbalance:
* communities are not able to use digital services
* people cannot access key information during crises
* there is very little documentation of languages in danger of dying out
* global inequality is made worse
[^1]: **Voice data:** Audio recordings of human speech. These recordings capture the acoustic features of spoken language, such as pronunciation, speaking patterns, and rhythm.
[^2]: **Dataset:** A collection of information that has been organized for use. A **voice dataset** is a collection of voice recordings (paired with transcription) with additional information (metadata) such as gender, age of the person recording to give more information on how the data set is constructed and to avoid bias. It is for use in research and for training or improving voice models.
[^3]: **Digital language divide:** When it comes to access to technology, there is a big gap between people who speak high-resource languages and those who speak low-resource languages. It means that many people cannot enjoy the benefits of digitalization.
# 2.3 Read speech data versus spontaneous speech data
Two types of voice data are needed to develop effective [language technology](#user-content-fn-1)[^1]. [**Read speech data**](#user-content-fn-2)[^2] is used for the foundation. [**Spontaneous speech data**](#user-content-fn-3)[^3] helps to make the system more robust and sound more natural.
### Read voice data
Read speech — also known as scripted speech — consists of recordings of speakers who read out a prepared text. This type of data:
* is highly controlled and structured
* has clear pronunciation and a steady pace
* follows standardized text formats
When building speech technologies for a new language, read speech data is often the first type of data that you would collect. It provides clean, predictable input for developing speech technology.
It's important to understand the difference between reading a text aloud and more natural communication. When they read aloud, people usually speak:
* more formally
* with fewer grammar errors
* with more complete sentences
* in a more monotone voice
* without using words like "um" or "uh"
* without restarting sentences
* following the rules of written language
This means that read speech can sometimes sound a bit artificial. Technologies that only use read speech may not work well in real-life situations.
### Spontaneous speech data
Spontaneous speech data consists of natural speech without a script. Speakers may not finish their sentences and they use regional expressions. They make constant changes to their speech, responding to feedback from listeners. This type of data:
* contains natural speech patterns like hesitations, and words like “um” or “uh”
* includes varied styles of speaking and speeds
* may include dialects and everyday phrases that you wouldn’t find in written language
* often contains overlapping speech, background noise, interruptions
* gives a better picture of real-world communication
You must include spontaneous voice data if you want to develop robust speech technologies that can handle real-world situations, but it is more difficult to process.
[^1]: **Language Technology (LT):** Technologies that focus on human language, including both spoken and written language. They can process, understand, and generate language. Examples are the tools on your phone or computer that understand and generate words, like translation apps or voice assistants. They allow us to communicate and interact with our devices with language. When you record a message and the device transforms it into text, or your phone suggests the next word in a message, that’s because of language technology. It makes digital tools more accessible, interactive and sometimes more efficient.
[^2]: **Read data:** Data that is read aloud.
[^3]: **Spontaneous voice data:** Recordings of natural speech with no script. These will contain hesitations, restarts, varied speaking patterns, and everyday phrases. They sound more like the way people actually talk.
# 3. Setting up a project to collect voice data
#### Chapter 3 overview:
{% hint style="info" %}
This chapter is for project coordinators, organizations, and linguists who want to set up a project to collect voice data. It explains how to:
* **define the scope of a project** in a new language or domain
* **design your project** and make a work plan
* **build your project team**.
You don’t need to be a technical expert to read this chapter. It is designed for anyone who wants to set up a project.
{% endhint %}
###
### Why set up a project to collect voice data?
Before you start a project to collect voice data, you need to define your goals. This is to make sure that the data will be useful. It is especially important in [low-resource language](#user-content-fn-1)[^1] projects. This is because if there is very little [voice data](#user-content-fn-2)[^2] available, you need to make sure that you don’t collect data that is not useful or relevant.
Here is a typical list of questions to ask:
* What are the main goals of your project?
* Who will it help?
* What problem do you want to solve?
* How will the data be used?
* How will your project support and empower the language community involved?
The answers will help you to design your project. For example:
* If you plan to use the datasets[^3] to build tools like speech recognition, the data must meet technical needs, such as language variant, quality, and metadata[^4].
* If you plan to use the datasets to build a speech solution for a specific use case, the data should match the context. For example, if you want to build a voice assistant for farmers, you may need to collect data in rural dialects, on topics relating to farming, and in real-world outdoor settings.
[^1]: **Low-resource language:** A language that has limited written or recorded materials and is rarely found in digital tools, data, or technology. This means that technologies like speech recognition or machine translation are not available for the language and are difficult to build. This may be due to a lack of written content, digital resources (like websites or videos), or support from organizations that develop language technology.
[^2]: **Voice data:** Audio recordings of human speech. These recordings capture the acoustic features of spoken language, such as pronunciation, speaking patterns, and rhythm.
[^3]: **Dataset:** A collection of information that has been organized for use. A **voice dataset** is a collection of voice recordings (paired with transcription) with additional information (metadata) such as gender, age of the person recording to give more information on how the data set is constructed and to avoid bias. It is for use in research and for training or improving voice models.
[^4]: **Metadata:** Extra information that gives some background to a dataset or parts of a dataset. Examples are demographics of the speakers (age, gender, accent), recording conditions (microphone type, level of background noise), or language-related details (dialect, speed of speaking, emotional tone).
# 3.1 Designing your project
A project to collect [voice data](#user-content-fn-1)[^1] often involves the following ***5*** stages (in reality this is is often an *iterative process*, giving space to improvements, scale etc as the data collection is ongoing):
*Smaller screens may require you to scroll to see all 5 stages*
Cover image
Defining the scope and setup
Define your project’s goals, target languages and dialects. Plan how you will find and support contributors. Decide on tools and platforms. Set timelines.
Find contributors whose voice you can record. Before you start collecting voice data, decide how you will divide up the prompts among contributors and set rules for recording (for example, recording duration, quality standards). Define your workflow for validating recordings.
You can find more details on these steps in later chapters of this playbook.
You will also need to think about including monitoring and evaluation throughout the project. You need to track your progress, get feedback from contributors, and check data quality. You will also need to evaluate the use and impact of the data after you have published it.
| **Case study: Defining the scope of CLEAR Global’s pilot project to collect voice data in Hausa, Kanuri, and Shuwa Arabic** |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
The first projects in TWB Voice collected voice data in Hausa, Kanuri, and Shuwa Arabic. The aim was to build open-source voice datasets in these languages.
to aid development of voice technology for specific use cases. For example, Hajiya, a text-based chatbot that CLEAR Global developed to help communities affected by crises in northeast Nigeria,
to work with communities to respond to user feedback in the TWB Voice platform and grow networks of contributors.
The project involved volunteer linguists from the TWB Community in northeast Nigeria.
Defining the scope of the pilot
With a 13-month timeline, targets were set to collect:
50-100hours of ASR data per language
10-20hours of single-speaker data for Text-to-Speech in Hausa and Kanuri
For the ASR datasets, the aim was to collect a wide variety of recordings and make the datasets openly available to others working to improve voice technology in these languages. The Hajiya chatbot was a useful example, but the priority here was to create datasets for broad use that included many dialects and speakers from different backgrounds. The speakers gave details of their dialect, age, gender, and education so that future users would understand the range of people included in the dataset.
In contrast, the TTS data collection was more focused, with the Hajiya chatbot as a specific example. During the chatbot’s development, community members commented that its text-only design made it hard to use for people with poor reading and writing skills. They suggested the kind of voice that would make the chatbot seem friendly and easy to use. The project chose the name Hajiya because it represents a respected, middle-aged woman and role model in Yobe, Borno, and Adamawa states of Nigeria. We chose voice artists for the Hausa and Kanuri TTS datasets that would match this persona.
Dealing with gaps in the body of available texts
One major challenge in defining the scope of the project was finding enough suitable texts for prompts. We found some sentences for Hausa and Kanuri during the project setup stage. However, we found very few for Shuwa Arabic—only about 1500 usable sentences with open licenses or owned by CLEAR Global. For all three languages, linguists created new prompts or changed existing ones so we had enough material relevant to the cultural context. Because the number of prompts was limited, we set up projects in TWB Voice so that up to three people could record each prompt.
Designing the workflow for quality checking (validation)
We only had a few hundred contributors but needed to be sure of good quality. So we designed a tiered system to check the quality of the recordings:
Contributors could listen back and self-check recordings before submitting them
If contributors had made at least one hour of voice recordings and had got 80% approval or higher, they were allowed to rate the recordings of others (tier 1).
Language Leads gained a “trusted linguist” status. This meant that we gave their ratings higher weighting (tier 2).
|
[^1]: **Voice data:** Audio recordings of human speech, usually paired with a transcription. These recordings capture the acoustic features of spoken language, such as pronunciation, speaking patterns, and rhythm.
[^2]: **Target language:** The language(s) for which you are collecting the voice data.
[^3]: **Dataset:** A collection of information that has been organized for use. A **voice dataset** is a collection of voice recordings (paired with transcription) with additional information (metadata) such as gender, age of the person recording to give more information on how the data set is constructed and to avoid bias. It is for use in research and for training or improving voice models.
[^4]: **TWB Voice:** A platform for collecting voice data. It was developed by CLEAR Global, who also own it. Users can make voice recordings to help with active data collection projects in TWB Voice by [signing up to the TWB Community](https://translatorswithoutborders.org/join-the-twb-community/). The main goal of TWB Voice is to help to develop voice technology for speakers of marginalized languages. For example, by creating the voice datasets that are needed to build language models for TTS and ASR.
[^5]: **Automatic Speech Recognition (ASR) or Speech-to-Text (STT):** ASR converts spoken language into text. It can be used in voice assistants and transcription services, for example. You may hear both terms, ASR and STT, and they are almost the same. But STT can be a semi-manual process, while ASR is fully automated. ASR is like a smart listener that turns spoken words into written text on your device. While it does create the text automatically, it often needs some human input to make sure everything is correct, it can make mistakes especially in languages that are less used in the digital space.
[^6]: **Model:** A computer-based system that has made use of data to learn patterns. It can make predictions or generate language. In speech technology, models use voice data to learn to recognize speech (converting audio to text) or to create speech (converting text to audio).
[^7]: **Voice technology:** Language technology that processes or generates spoken words.
[^8]: **TWB Community:** A global community of over 100,000 linguists. They donate their time and skills to translate information for millions of people around the world. They help people to get the information they need and want.
[^9]: **Text-to-Speech (TTS):** Technology that converts written text into spoken language. It can also generate audio speech. You can find TTS in accessibility tools like screen readers and in virtual assistants. It brings written texts to life through spoken words. If your phone reads out the messages you get, or an audiobook tells you your favorite story, this is because of TTS technology.
[^10]: **Community members:** People at the center of a project who contribute by recording and validating data. In this context, community refers to their shared interest in contributing to data collection and the languages they speak. Community members are well positioned to provide feedback on linguistic aspects and offer input on the project's direction and needs.
[^11]: **Language Leads (LLs):** Language experts with lots of experience. They can do spot checks to ensure quality and can give feedback.
[^12]: **Rating:** An individual quality assessment by a contributor. They either approve or reject a piece of language data (recording in the case of voice data) and base their rating on the pass/fail guidelines. Several ratings may be needed to decide whether this data has passed or failed for quality.
# 3.2 Creating a work plan for voice data collection
Work planning means organizing tasks, resources, and timelines to complete a project well. When collecting [voice data](#user-content-fn-1)[^1], a work plan helps you to manage complex steps. These steps involve people, technology, quality checks, and community involvement, especially in low-resource or challenging settings.
Key parts of a work plan include:
* clear project phases
* milestones with goals you can measure (like “5,000 prompts uploaded” or “10 hours of recordings validated”)
* a detailed timeline to show the order of tasks and which ones depend on others (for example, contributor onboarding depends on the platform being ready)
* resource planning so that you use staff, software, and funds efficiently.
Ways to be more efficient in a work plan include:
* running tasks in parallel when possible. Examples from [TWB Voice](#user-content-fn-2)[^2] projects include:
* assessing the capacity of the community and starting to engage with them while setting up the projects and creating text prompts,
* recording and validating the data in parallel,
* preparing licensing while data collection projects are in progress.
* building in extra time, especially with [low-resource languages](#user-content-fn-3)[^3]. With the TWB Voice pilot projects, extra time was needed:
* to create and clean text prompts because resources were scarce,
* to engage and train contributors who were new to digital tools,
* to check the quality of the recordings—only those who had recorded at least one hour of speech were allowed to rate others, so the pool of available raters was small relative to those recording.
| **Key tips: How can I make a practical plan for potential risks?** |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
Unexpected delays and challenges are common in low-resource language projects. You should include a risk management matrix in your work plan to help you plan for these.
The basic principle of a risk management matrix is to:
identify potential risks: for example, delays in the available texts, bugs on the platform that stop you from collecting data, or low community engagement.
assess each risk by how likely it is and its impact using a scale (often low/medium/high) to assess how likely the risk is to happen and how much it would impact delivery of the project.
plan what to do to prevent each risk, and what steps you will take if it happens.
|
[^1]: **Voice data:** Audio recordings of human speech. These recordings capture the acoustic features of spoken language, such as pronunciation, speaking patterns, and rhythm.
[^2]: **TWB Voice:** A platform for collecting voice data. It was developed by CLEAR Global, who also own it. Users can make voice recordings to help with active data collection projects in TWB Voice by [signing up to the TWB Community](https://translatorswithoutborders.org/join-the-twb-community/). The main goal of TWB Voice is to help to develop voice technology for speakers of marginalized languages. For example, by creating the voice datasets that are needed to build language models for TTS and ASR.
[^3]: **Low-resource language:** A language that has limited written or recorded materials and is rarely found in digital tools, data, or technology. This means that technologies like speech recognition or machine translation are not available for the language and are difficult to build. This may be due to a lack of written content, digital resources (like websites or videos), or support from organizations that develop language technology.
# 3.3 Building your team
The size of your team and the roles you need for a project to collect [voice data](#user-content-fn-1)[^1] will depend on your project’s aims, context, and available resources. [**Community members**](#user-content-fn-2)[^2] are at the center. They make recordings, check the quality of the data, and give feedback to the team and to other contributors, so they should be involved in shaping the project from the start.
Here are the key roles and typical responsibilities of a project team that helps community members to contribute with their voices:
* **Community engagement lead:** supports contributors, organizes training, creates guidance materials, and collects and responds to feedback.
* **Language expert:** helps edit or develop the available texts, advises on dialect and linguistic features, and helps with translation or content for the community. Note: not all voice contributors are linguists, and not all linguists will want to make recordings. These can be two distinct roles.
* **NLP specialist:** makes sure that the data meets quality standards for its intended use, from defining scope through to publication.
* **Technical lead/engineers:** maintains the data collection platform, deals with technical issues, and makes sure that data is handled and stored securely.
* **Data protection specialist:** takes care of privacy, processes for informed consent, and ethical data use.
* **Project coordinator:** manages timelines and budgets, and makes sure there is good communication between team members.
| **Case study: The team behind CLEAR Global’s TWB Voice projects in Hausa, Kanuri, and Shuwa Arabic** |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
Three core teams supported CLEAR Global’s TWB Voice projects:
Community team, including:
Community Lead: Designed and led the strategy for community engagement, organized feedback surveys, and ran a contributor recognition program. This role helped us to identify the difference between shared challenges and challenges specific to a language.
Language Leads (Hausa, Kanuri, Shuwa Arabic): Each language had a lead who helped with linguistic tasks, checked the quality of contributions, and kept up direct communication with their community.
Technical team, including:
a computational linguist who helped design prompts, advised on quality guidelines for data collection, checked data quality at regular intervals during data collection, and helped with processing and publication of the datasets.
platform developers who maintained the TWB Voice recording platform and dealt with technical issues that users reported during data collection.
Data Protection Lead to ensure compliance with data protection standards, including GDPR.
Project coordination team, including:
two project managers: one to oversee the overall project timeline (from defining the scope to dataset publication), and a second to focus on daily tasks in the active data collection projects and contributor support.
a Monitoring, Evaluation, Accountability, and Learning (MEAL) specialist who designed feedback mechanisms, a monitoring framework, and a learning review to inform future projects.
There were also some supporting roles, including finance, HR, logistics and a communications specialist. Most of the work was done remotely. Team leads met every two weeks, and sub-teams more often to manage daily tasks. Slack, a platform for team communication, was used for quick updates and to track issues, especially for resolving tech problems quickly.
Key learnings on team structure from the pilot projects:
Combine or split roles based on capacity. With smaller teams, one person could take on more than one role—for example, a data protection lead could also help with project management, or a Language Lead may also manage community engagement.
Focus on critical functions beyond the set roles and responsibilities. For example, we used tools like Whatsapp for communication. This meant that multiple team members had to monitor and help with communications in those channels. It was also helpful that several people understood the structure of the TWB Voice platform. This helped avoid delays when the main team member was not available.
The workload of the Language Lead varied a lot, and sometimes they had too much work. In future projects, we would try to separate community engagement from linguistic tasks. We would also train contributors to help with activities like collecting and organizing the voice recordings. This would help to avoid bottlenecks.
|
[^1]: **Voice data:** Audio recordings of human speech. These recordings capture the acoustic features of spoken language, such as pronunciation, speaking patterns, and rhythm.
[^2]: **Community members:** People at the center of a project who contribute by recording and validating data. In this context, community refers to their shared interest in contributing to data collection and the languages they speak. Community members are well positioned to provide feedback on linguistic aspects and offer input on the project's direction and needs.
[^3]: **TWB Voice:** A platform for collecting voice data. It was developed by CLEAR Global, who also own it. Users can make voice recordings to help with active data collection projects in TWB Voice by [signing up to the TWB Community](https://translatorswithoutborders.org/join-the-twb-community/). The main goal of TWB Voice is to help to develop voice technology for speakers of marginalized languages. For example, by creating the voice datasets that are needed to build language models for TTS and ASR.
[^4]: **Recognition program**: A system of rewards (points, certificates, or money) to motivate contributors.
[^5]: **Language Leads (LLs):** Language experts with lots of experience. They can do spot checks to ensure quality and can give feedback.
[^6]: **The General Data Protection Regulation (GDPR):** A European Union law that deals with personal data. It tells us how to collect, process, store, and share data. It makes sure people have control over their personal data. It also ensures that organizations handle such data in a transparent, secure, and lawful way.
# 4. Guidelines for sentence and prompt collection
#### Chapter 4 overview:
{% hint style="info" %}
This chapter is for linguists, content creators, technical developers, and project managers who are preparing prompts for voice data collection. We'll cover:
* finding content sources for your language and domain
* handling licensing issues when you use existing content
* processing text with automated and manual methods
* creating effective prompts that result in natural speech
Most sections are suitable for non-technical team members, but section 4.3 is for people with programming expertise for text processing pipelines.
{% endhint %}
Prompts are the sentences or instructions that guide users when they record in [TWB Voice](#user-content-fn-1)[^1]. Prompts that are well prepared will result in recordings that are of high quality. They will be suitable for both [Text-to-Speech (TTS)](#user-content-fn-2)[^2] and [Automatic Speech Recognition (ASR)](#user-content-fn-3)[^3] applications.
###
### Types of prompt
There are two main types of prompt:
* **Read speech prompts:** specific sentences that users read aloud exactly as written
* **Spontaneous speech prompts:** open-ended questions or descriptions of images that encourage people to speak freely
Each type has a specific purpose when developing [voice technology](#user-content-fn-4)[^4]. Read speech prompts give you controlled, predictable speech patterns. Spontaneous speech prompts create more natural speech patterns.
What you need to know to collect and prepare high-quality text prompts:
* where to find the right kind of sentences for your language and domain[^5]
* how to handle licensing issues if you use existing content
* methods of processing text automatically to prepare it for recording
* guidelines for checking sentences for quality and to make sure they are usable
* special things to consider when you collect data with images
* best practices for creating spontaneous speech prompts to generate natural speech
These guidelines will help you build an effective collection of prompts for your [voice data](#user-content-fn-6)[^6] project. They are helpful whether you're working with a widely spoken language or one with limited digital resources.
[^1]: **TWB Voice:** A platform for collecting voice data. It was developed by CLEAR Global, who also own it. Users can make voice recordings to help with active data collection projects in TWB Voice by [signing up to the TWB Community](https://translatorswithoutborders.org/join-the-twb-community/). The main goal of TWB Voice is to help to develop voice technology for speakers of marginalized languages. For example, by creating the voice datasets that are needed to build language models for TTS and ASR.
[^2]: **Text-to-Speech (TTS):** Technology that converts written text into spoken language. It can also generate audio speech. You can find TTS in accessibility tools like screen readers and in virtual assistants. It brings written texts to life through spoken words. If your phone reads out the messages you get, or an audiobook tells you your favorite story, this is because of TTS technology.
[^3]: **Automatic Speech Recognition (ASR) or Speech-to-Text (STT):** ASR converts spoken language into text. It can be used in voice assistants and transcription services, for example. You may hear both terms, ASR and STT, and they are almost the same. But STT can be a semi-manual process, while ASR is fully automated. ASR is like a smart listener that turns spoken words into written text on your device. While it does create the text automatically, it often needs some human input to make sure everything is correct, it can make mistakes especially in languages that are less used in the digital space.
[^4]: **Voice technology:** Language technology that processes or generates spoken words.
[^5]: **Domain:** The subject area or setting in which we use language. Examples are healthcare, farming, or education. Each domain has its own special terms and language patterns.
[^6]: **Voice data:** Audio recordings of human speech. These recordings capture the acoustic features of spoken language, such as pronunciation, speaking patterns, and rhythm.
# 4.1 Where can I find sentences for my language/domain?
### Understanding domains and content sources
What do we mean by "domain[^1]" when collecting voice data?
**Domain** means the subject area or context in which the language is used. For example, healthcare, farming, and legal services are all different domains. They each have their own terminology and language patterns. If you focus on the relevant domain, you can be sure that:
1. the resulting voice model[^2] will be able to handle terminology from your use case and will be accurate,
2. the vocabulary used reflects how people actually speak in real-life situations,
3. the models will be well suited to the intended use, so their impact will be stronger
Collecting data in a domain-specific way is very important for languages that are not widely spoken as resources for these languages may be limited.
### Digital versus non-digital sources
### Repurposing existing content
One of the most efficient methods is to repurpose content that you've already developed or have access to:
* **Previous projects:** past publications, translations, or localization projects often contain sentences in your [target language](#user-content-fn-3)[^3] that have been checked for quality
* **Communications materials:** materials created for community outreach, for education, or for information campaigns
* **Content generated by users:** questions, answers, and feedback that you have collected through your services (check permissions)
### Online sources
There are various sources of sentences you could use on the internet. Availability and permissions to use them vary a lot by language and domain:
{% columns %}
{% column %}
{% endcolumn %}
{% column %}
{% endcolumn %}
{% endcolumns %}
{% columns %}
{% column %}
{% endcolumn %}
{% column %}
{% endcolumn %}
{% endcolumns %}
{% columns %}
{% column %}
{% endcolumn %}
{% column %}
{% endcolumn %}
{% endcolumns %}
If you use online sources, always check the licensing terms and say where the content came from.
### Community-based collection
For languages with limited written resources, it is very helpful to work directly with [community members](#user-content-fn-4)[^4] or linguists:
* **Community workshops:** Bring together speakers to generate sentences about their daily lives and local topics
* **Storytelling sessions:** Record and transcribe traditional stories (remember that transcription means extra work). You can then process these recordings to increase the amount of voice data you have.
* **Surveys and interviews:** Ask community members about specific topics that are relevant to your domain.
* **Expert consultation:** Work with linguists or experts in your domain to generate terminology and phrases that relate to your domain.
Remember that generating new content means extra work. But you may need to do this if your language has only limited resources.
### Domain-specific resources
If your domain is specialized, there are some targeted resources you can use:
### Make sure your collection is well-balanced
Try to get a wide variety in your sentence collection::
* **Varying length:** include short, medium, and longer sentences. Keep in mind limitations on recording time. Aim at sentences of 15-20 seconds maximum.
* **Sentence types:** statements, questions, exclamations, and commands
* **Grammar structure:** different tenses, types of sentence, and levels of complexity
* **Range of different speakers:** content from different age groups, genders, and backgrounds
* **Variety of situations:** formal and informal language, different social settings, sounds that people make (like “Oh!” and “Aha” in English)
When organizing your collection, use a clear system:
* Create spreadsheets with separate columns for original sentences and normalized versions ([explained later](https://d.docs.live.net/d189fa3c37514a9a/Documents/01%20Freelance%20paperwork/23%20TWB%20Plain%20Language/Tasks/03%2005%2006%202025%20Dona/PL%20Edit_TWB%20Voice%20Program%20Playbook_Part%202_Sentence%20and%20prompt%20collection%20-%20Copy.docx#_ohcpwwmkgca4)) and notes, where necessary
* Make a note of the sources and authors of your sentences so you can be sure to credit them
* Track metadata[^5] like domain categories, sentence length, and completion status
* Set clear targets for how many sentences you need in each category
| **Key tips: How many sentences do I need?** |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
The ideal number of sentences depends on the size, resources, and goals of your project. For reference:
1,000 sentences with an average length of 7 seconds will give you about 2 hours of recorded speech.
For ASR development, the smallest usable dataset would be at least 10 hours (roughly 10,000-20,000 sentences). More complex models may need 100+ hours.
TTS systems can work at a basic level with fewer sentences (5,000-10,000) if they're recorded by a single professional speaker in controlled conditions.
If you have access to plenty of sources of digital text data, collect as many sentences as you can. If you are collecting texts manually, there will be practical limitations so you will need to plan carefully.
Ideally, each sentence should be recorded once by a single speaker. But if you only have a limited collection of sentences, you can get multiple speakers to record the same sentences. This approach is helpful when you are having problems creating a wide variety of content but you still need a lot of voice data—made possible by having a large number of contributors.
|
[^1]: **Domain:** The subject area or setting in which we use language. Examples are healthcare, farming, or education. Each domain has its own special terms and language patterns.
[^2]: **Model:** A computer-based system that has made use of data to learn patterns. It can make predictions or generate language. In speech technology, models use voice data to learn to recognize speech (converting audio to text) or to create speech (converting text to audio).
[^3]: **Target language:** The language(s) for which you are collecting the voice data.
[^4]: **Community members:** People at the center of a project who contribute by recording and validating data. In this context, community refers to their shared interest in contributing to data collection and the languages they speak. Community members are well positioned to provide feedback on linguistic aspects and offer input on the project's direction and needs.
[^5]: **Metadata:** Extra information that gives some background to a dataset or parts of a dataset. Examples are demographics of the speakers (age, gender, accent), recording conditions (microphone type, level of background noise), or language-related details (dialect, speed of speaking, emotional tone).
[^6]: **Dataset:** A collection of information that has been organized for use. A voice dataset is a collection of voice recordings and includes extra information. It is for use in research and for training or improving voice models.
# 4.2 License issues
It’s very important that you have a good understanding of licensing when you collect sentences from existing sources. If you use content without proper permissions, you may end up having legal issues. There may also be limits on how you can use or share your voice datasets[^1].
### Types of license
These are the main categories of content license:
* **Closed/proprietary licenses:** These restrict rights to use the content. You will normally have to get explicit permission to use it. Examples include copyrighted news articles, books, and most commercial content.
* **Open licenses:** These allow various forms of reuse, with different levels of freedom. The most common open licenses are [Creative Commons (CC)](#user-content-fn-2)[^2] licenses.
* [**Public domain:**](#user-content-fn-3)[^3] This is content with no copyright restrictions. Anyone can freely use it without permission.
### Understanding Creative Commons licenses
Creative Commons (CC) licenses are a standardized way for content creators to give permission for their work to be used. Here are the most common types of CC license:
* **CC BY** (Attribution): You can use, change, and redistribute the content, even for commercial use. But you must credit the original creator.
* **CC BY-SA** (Attribution-ShareAlike): Similar to CC BY, but derivative works based on the original content also have to use the same license.
* **CC BY-NC** (Attribution-NonCommercial): Allows reuse if you credit the creator, but commercial use is not allowed.
* **CC BY-ND** (Attribution-NoDerivatives): Allows redistribution if you credit the creator, but you are not allowed to make changes.
* **CC0** (Public Domain Dedication): Creator gives up all rights and places the work in the public domain.
For more detailed information about Creative Commons licenses, go to the [Creative Commons website](https://creativecommons.org/licenses/).
### Where to find license information
You can find the license details in various places depending on the source:
* **Websites:** Look for "Terms of Service," "Terms of Use," or "Legal" links. These are often at the bottom of web pages. News sites, blogs, and websites of organizations usually have this information in their footer.
* **Datasets:** Check the documentation, README files, or metadata[^4] that came with the dataset. Popular platforms like [Hugging Face](#user-content-fn-5)[^5], Kaggle, or GitHub ask for license information for datasets that you upload.
* **Published materials:** Books, articles, and other published content often have copyright notices on their title pages or in the first section.
* **Open data portals:** Government data, academic platforms, and open data projects usually have clear licensing information on their download pages.
If you can't find the license information, it’s best to assume the content is copyrighted and you will need permission.
### When licenses don’t give you enough freedom
If you find some useful content, but the licensing is restrictive:
1. **Contact the rights holder:** Many content owners are happy to allow use of their content if it is for a non-commercial or research project. Give them a clear explanation of your project. Say how you'll use their content, and how it will help the community. Make sure you explain well what you plan to do with the content. Tell them whether you intend to republish sentences, and about your plans to build voice technologies.
2. **Document permissions:** If you get permission, keep a written record of all agreements.
3. **Inspiration is free!:** If you don’t get permission, create similar content with licenses that allow more freedom. Or create your own content. You are not allowed to take copyrighted sentences, but you can get inspiration from them!
4. **Consult legal experts:** For larger projects or if you have to deal with commercial organizations, you may need to get legal advice.
| **Case Study: CLEAR Global’s collection of books in Kanuri** |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
Kanuri is a language spoken by around 10 million people across Nigeria, Niger, Chad, and Cameroon. Although so many people speak this language, there is very little digital content in Kanuri. Text resources are very limited, both online and in digital format.
When CLEAR Global set out to build voice technology for Kanuri, we faced a major challenge: there was almost no digital text data available to work with. But we knew that several authors had written books in Kanuri. These books could be important sources for sentence collection.
We reached out to these authors through our Kanuri linguist and organized face-to-face meetings. In these meetings, we explained our project in simple terms—we needed their written material to develop AI applications that could speak Kanuri. We made it clear that we were interested in the language in their books rather than the stories.
"We don’t want to republish your books as literature," we explained. "We want to take the individual sentences and use them to teach computers how to speak Kanuri." We used simple language to help the authors to understand how their work could help in the development of language technology.
We suggested a fair arrangement. Authors would share their books in digital format (Word files when available). We would take sentences from them, and in return, pay them a symbolic fee per word. We also promised to credit them when publishing the data.
This idea brought great results. With the authors' permission, we created the first openly available text corpus (collection of sentences) in Kanuri. It was published on Hugging Face with full credit to the original authors and their works. With this collection of texts, we could then create the first Kanuri voice corpus (collection of voice data). This made it possible for the first time for Kanuri speakers to access digital technologies in their language.
The reason this approach was successful was the human connection. We met face-to-face, we explained our goals in simple language, we offered fair payment, and we made sure the authors were credited. This built trust with the Kanuri authors. We could adapt this model for other languages with limited digital resources if there are printed materials available. This shows that, even when there is very little digital content, working with people in creative ways can give us access to useful language data.
|
### Licensing your own collections of sentences
The sentences you collect are important resources for language technology development. Consider the following when you license your own collections:
1. **Choose a suitable license:** CC BY or CC BY-SA licenses are common for datasets intended for broad use. They make sure people are credited but allow flexibility.
2. **Document clearly:** Include a LICENSE.txt file with your dataset and add license information to dataset metadata. Platforms like Hugging Face and Github allow you to add these automatically during the creation of your dataset.
3. **Consider your goals:**
* For maximum impact and reuse, choose licenses like CC BY or CC0 that allow a lot of freedom
* To make sure new versions of the content are available for use, use CC BY-SA
* If you are worried about commercial use, maybe use CC BY-NC
4. **Respect the rights of contributors:** If your sentences come from [community members](#user-content-fn-9)[^9], make sure you have their permission to license the content. You can also credit them by mentioning their names. Only do this if you have their permission and they don’t want to stay anonymous. For TTS projects, it’s very important that you don’t give away the contributors’ identities. This will avoid possible misuse of the TTS models made with their data.
5. **Include proper credits:** When you publish your dataset, credit all sources that contributed to your collection.
If you publish your collections of sentences with clear licensing, it not only helps other developers. It will also help to grow the amount of resources for your language. This is especially important for [low-resource languages](#user-content-fn-10)[^10].
Remember that licensing choices can impact how widely your data can be used to develop voice technologies. Licenses that allow more freedom generally result in greater use and impact.
[^1]: **Dataset:** A collection of information that has been organized for use. A **voice dataset** is a collection of voice recordings (paired with transcription) with additional information (metadata) such as gender, age of the person recording to give more information on how the data set is constructed and to avoid bias. It is for use in research and for training or improving voice models.
[^2]: **Creative Commons (CC) licenses:** A set of standard copyright licenses that let the creator of a piece of work choose which rights they want to keep and which they will give up.
[^3]: **Domain:** The subject area or setting in which we use language. Examples are healthcare, farming, or education. Each domain has its own special terms and language patterns.
[^4]: **Metadata:** Extra information that gives some background to a dataset or parts of a dataset. Examples are demographics of the speakers (age, gender, accent), recording conditions (microphone type, level of background noise), or language-related details (dialect, speed of speaking, emotional tone).
[^5]: **Hugging Face:** An online platform where researchers and developers share AI models, datasets, and applications.
[^6]: **Voice technology:** Language technology that processes or generates spoken words.
[^7]: **Language Technology (LT):** Technologies that focus on human language, including both spoken and written language. They can process, understand, and generate language. Examples are the tools on your phone or computer that understand and generate words, like translation apps or voice assistants. They allow us to communicate and interact with our devices with language. When you talk to a virtual assistant like Siri or Alexa, or your phone suggests the next word in a message, that’s because of language technology. It makes technology more accessible and user-friendly.
[^8]: **Corpus:** A collection of text or speech data that you can use to train language technology.
[^9]: **Community members:** People at the center of a project who record and validate data. They also give feedback to the team and to other members.
[^10]: **Low-resource language:** A language that has limited written or recorded materials and is rarely found in digital tools, data, or technology. This means that technologies like speech recognition or machine translation are not available for the language and are difficult to build. This may be due to a lack of written content, digital resources (like websites or videos), or support from organizations that develop language technology.
# 4.3 Automatic and manual processing of sentences
This section explains how to transform raw text documents to a high-quality sentence set ready to record and then suitable for training[^1] models[^2] through both automatic and manual techniques.
### Understanding text processing pipelines
A text processing pipeline typically follows these ***6*** stages:
*Smaller screens may require you to scroll to see all 6 stages*
Cover image
Document collection
Gathering source materials in various formats (PDF, HTML, Word, plain text)
For a practical example of a text processing project, you can explore this open-source [Aranese text corpus creation project](https://github.com/CollectivaT-dev/aranese-text-corpus/tree/main). This repository contains a Python notebook that implements the entire pipeline for Occitan Aranese—a l[ow-resource language](#user-content-fn-3)[^3] spoken in Spain.
If you are curious or ready to explore details around each step - continue reading below, if you want to continue getting familiar with other more general aspects of data collection, you can skip to [4.4 Reviewing the sentences](/4.-guidelines-for-sentence-and-prompt-collection/4.4-reviewing-the-sentences). You can always come back here later!
Let's explore each stage in more detail.
### Text extraction techniques
Different document formats require different extraction approaches:
* **Plain text files (.txt):** These can be processed directly
* **Structured documents (Word, HTML):** Use libraries like BeautifulSoup (for HTML) or docx2txt (for Word) to extract text while preserving structure
* **PDFs:** Use libraries like PyPDF2 or pdfplumber to extract text
* **Scanned documents:** Require [Optical Character Recognition](#user-content-fn-4)[^4] (OCR)
This code uses the Tesseract OCR engine with the Occitan language model ("oci") to convert image files extracted from PDFs into text. For low-resource languages where OCR models may not exist, you might need to use a model from a closely related language or train a custom model.
```python
# Extract text from PDF images using OCR
def ocr_image_to_text(image_path):
image = Image.open(image_path)
text = pytesseract.image_to_string(image, lang="oci")
return text
```
It's important to note that OCR output often contains errors, especially for low-resource languages or documents with poor image quality. These errors can include character misrecognition, incorrect word breaks, and formatting issues. This is why the Aranese corpus[^5] project implements a post-OCR correction step using a large language model.
For your language, you can implement OCR correction through:
1. **Rule-based corrections:** Create a set of rules to fix common OCR errors in your language, such as frequently misrecognized characters or typical formatting issues.
2. **Dictionary-based corrections:** Use a dictionary of words in your language to detect and correct non-existent words that might be OCR errors.
3. **LLM-assisted corrections:** As shown in the Aranese project, you can use LLMs with clear instructions to clean up OCR output. This works particularly well for languages the LLM has been trained on. You can enhance results by providing the LLM with specific rules about your language's orthography like the character set of your language or a vocabulary list.
### Sentence segmentation
Accurate sentence segmentation is essential for voice recording, as recordings are typically organized sentence by sentence. Punctuation marks like periods, question marks, and exclamation points usually indicate sentence boundaries.
Basic segmentation can be accomplished using regular expressions or natural language processing libraries. For example:
```python
import re
# Simple segmentation using regular expressions
def segment_sentences(text):
# Split on period, exclamation mark, or question mark followed by space or newline
sentences = re.split(r'[.!?][\s\n]', text)
# Clean up each sentence
sentences = [s.strip() for s in sentences if s.strip()]
return sentences
```
For more sophisticated segmentation, specialized libraries are available:
```python
from nltk.tokenize import sent_tokenize
# More advanced segmentation using NLTK
sentences = sent_tokenize(text, language='english')
```
While these libraries work well for high resourced and/or latin-based languages, for less-resourced languages, you might need to develop custom rules based on your language's punctuation patterns.
#### Filtering sentences
Not all extracted sentences will be suitable for voice recording. It's essential to filter sentences based on several criteria:
1. **Length**: Very short sentences may not provide enough context, while very long sentences can be difficult to record
2. **Character set:** Sentences containing symbols or characters outside your language's alphabet should be filtered out
3. **Content:** Sentences with sensitive content, code snippets, tabular data, or excessive technical jargon
4. **Duplicates:** Remove duplicate sentences to maximize diversity
### Using AI to assist with script development
Modern large language models (LLMs) can help write and refine text processing scripts. For example, you could prompt an LLM with:
```markup
I have a directory of text files in [LANGUAGE] that I need to process
for a voice corpus. Write a Python script that:
1. Extracts sentences from each file
2. Keeps only sentences that are between 5 and 400 characters
3. Removes sentences with non-[LANGUAGE] characters
4. Removes duplicate sentences
5. Outputs the results to a single file with one sentence per line
Include error handling and progress reporting.
```
This prompt can be improved by:
1. Specifying the exact alphabet of your language
2. Providing examples of "good" and "bad" sentences
3. Including any special rules for your language's punctuation
4. Describing any format-specific handling (PDFs, HTML, etc.)
5. Mentioning any domain[^6]-specific filtering (e.g., excluding medical terminology)
### Sentence normalization
Normalization is the process of converting text to a standard format suitable for speech applications. This is particularly important for ASR ([Automatic Speech Recognition](#user-content-fn-7)[^7]) and TTS (Text-to-Speech)[^8] models, which need consistent representations of words.
Key normalization tasks include:
1. **Expanding abbreviations** e.g. converting "Dr." to "Doctor", "Mr." to "Mister", etc.
2. **Converting numbers** e.g writing out "123" as "one hundred twenty-three"
3. **Handling dates and times** e.g formatting "08/12/2024" as "August twelfth, two thousand twenty-four"
4. **Standardizing symbols** e.g. convert "&" to "and", "@" to "at", etc.
5. **Removing unnecessary punctuation** e.g. removing hyphens, slashes, and other symbols that wouldn't be spoken
For complex normalization, you might need language-specific rules and dictionaries.
### Practical considerations for large projects
When working with large text collections:
1. **Processing time:** OCR and complex text processing can be time-consuming. Consider dividing the task into multiple CPUs (parallel processing) for large datasets[^9].
2. **Storage management:** Maintain organized directories for raw text, processed text, and final sentences.
3. **Quality control:** Implement random sampling to check the quality of automatically processed sentences.
4. **Iterative refinement:** Start with a small sample, refine your process, then apply to the full dataset.
5. **Documentation:** Keep detailed records of all processing steps and decisions, especially custom rules.
[^1]: **Training**: Teaching a computer-based model to recognize patterns. To do this, you need to show it large amounts of data as examples.
[^2]: **Model:** A computer-based system that has made use of data to learn patterns. It can make predictions or generate language. In speech technology, models use voice data to learn to recognize speech (converting audio to text) or to create speech (converting text to audio).
[^3]: **Low-resource language:** A language that has limited tools, data, or technology. This means that things like speech recognition, machine translation, or other language technologies are not available. This may be because there is not enough written material or digital resources, such as websites or videos in this language. Or not enough support from organizations that could make language technology.
[^4]: **Optical Character Recognition (OCR):** Technology that converts pictures of written text (like scanned documents) into text that a computer can read. This makes it possible to take content from printed materials and process it digitally.
[^5]: **Corpus:** A collection of text or speech data that you can use to train language technology.
[^6]: **Domain:** The subject area or setting in which we use language. Examples are healthcare, farming, or education. Each domain has its own special terms and language patterns.
[^7]: **Automatic Speech Recognition (ASR) or Speech-to-Text (STT):** ASR converts spoken language into text. It can be used in voice assistants and transcription services, for example. You may hear both terms, ASR and STT, and they are almost the same. But STT can be a semi-manual process, while ASR is fully automated. ASR is like a smart listener that turns spoken words into written text on your device. While it does create the text automatically, it often needs some human input to make sure everything is correct, it can make mistakes especially in languages that are less used in the digital space.
[^8]: **Text-to-Speech (TTS):** Technology that converts written text into spoken language. It can also generate audio speech. You can find TTS in accessibility tools like screen readers and in virtual assistants. It brings written texts to life through spoken words. If your phone reads out the messages you get, or an audiobook tells you your favorite story, this is because of TTS technology.
[^9]: **Dataset:** A collection of information that has been organized for use. A **voice dataset** is a collection of voice recordings (paired with transcription) with additional information (metadata) such as gender, age of the person recording to give more information on how the data set is constructed and to avoid bias. It is for use in research and for training or improving voice models.
# 4.4 Reviewing the sentences
Automated text processing is powerful but not perfect. Even the most sophisticated systems can produce sentences that are not suitable for voice recording. This is why having the sentences reviewed by a human is a key step in building a high-quality collection of sentences.
### The importance of human review
With automated extraction, you often get sentences that look okay at first glance but have subtle issues. For example, a sentence might be complete in terms of grammar but may include content that is culturally sensitive. Or it might use vocabulary from a different variant of the language. We need human judgement to identify and correct these issues.
### Setting up a review process
A clear and simple approach is to put the sentences into a spreadsheet with headed columns for the review process. For example:
| Original Sentence | Revised Sentence | Normalized Version | Comments | Status |
| ---------------------------------- | --------------------------------------------------- | ----------------------------------------------------------- | ------------------------------------------ | -------- |
| Original Sentence | Revised Sentence | Normalized Version | Comments | Status |
| "The temp. was 32°C yesterday." | "The temperature was 32 degrees Celsius yesterday." | "The temperature was thirty-two degrees Celsius yesterday." | Expanded abbreviation and symbols | Approved |
| "Do NOT touch—dangerous!" | "Do not touch. It is dangerous." | "Do not touch. It is dangerous." | Fixed formatting and capitalization | Approved |
| "@everyone joins the meeting tmrw" |
|
| Contains social media formatting, informal | Rejected |
This structure allows reviewers to track changes, add normalized versions if needed, and document their decisions. When various people are working on a project, you can use cloud-based spreadsheets. These allow multiple reviewers to gain access at the same time.
One tip to make this step more efficient is to skip any sentence that will take some time to revise and correct. You can of course do this if you have plenty of sentences and it doesn’t matter if some of them are lost.
### What to look for during review
When reviewing sentences, look at the following:
**Language integrity:** Make sure the sentence is in the [target language](#user-content-fn-1)[^1] and dialect. But be mindful of the difference between natural code-mixing and unintended language mixing. Many languages include loanwords or code-switching as a part of everyday speech. For example, in Hindi, English words like "mobile," "computer," or "internet" are commonly used and accepted. Similarly, "sugar" is often used to mean diabetes in many South Asian languages.
**Cultural fit:** Check that content is culturally sensitive and fitting for voice contributors to read aloud. This means avoiding sentences that contain offensive language, references that are not appropriate for the culture in question, or content that may be traumatic.
**Speakability:** Read the sentence aloud to make sure it flows naturally. Some sentences may be correct in grammar terms but awkward and difficult to read out.
**Consistency:** Make sure that formatting, terminology, and style are the same across the sentence set. If you are not consistent, it can confuse both voice contributors and the models trained on this data.
**Information that allows people to be identified:** Remove or change any sentences that contain personal data such as real names, phone numbers, addresses, or ID numbers. For example, "Contact Dr. Sarah Johnson at +1-555-123-4567 for an appointment" should be changed to: "Contact the doctor at the clinic for an appointment." This protects privacy and ensures that your voice dataset[^2] doesn’t contain any sensitive information that could cause a problem if you publish it. Be very careful with medical, financial, or administrative texts that often contain personal details.
\
[^1]: **Target language:** The language(s) for which you are collecting the voice data.
[^2]: **Dataset:** A collection of information that has been organized for use. A **voice dataset** is a collection of voice recordings (paired with transcription) with additional information (meta data) such as gender, age of the person recording to give more information on how the data set is constructed and to avoid bias. It is for use in research and for training or improving voice models.
# 4.5 Guidelines for collecting image data
Image-based prompts can be very helpful tools to generate spontaneous speech in projects to collect [voice data](#user-content-fn-1)[^1]. Unlike [read prompts](#user-content-fn-2)[^2] where speakers read out prepared text, image prompts produce natural, varied responses as people describe what they see.
### Choosing suitable images
When you are collecting images for your voice data project, try to find pictures that are familiar and relevant to the local culture. Google Maps street view and photos of the local area uploaded by the community can provide helpful images. Local contributors will be able to relate to and respond to such images. They should show everyday scenes and objects, common activities, and local settings that people will recognize and can describe.
|
|
|
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|  |  |
Asking users to describe generic images like these can help you collect voice data.
### Type of content to choose
Always choose images with clear, specific content and details that contributors can describe. Don’t use sensitive content related to conflict, disasters, or illness, as these may trigger negative feelings. This will then stop the natural flow of speech. And don’t use images with faces or people that they may recognize (apart from public figures like the president, actors, singers etc.).
### Using image prompts
When showing image prompts to contributors, give them simple, open-ended instructions. For example, "Describe what you see in this image" or "Tell me what's happening in this picture." Aim for responses that last between 10 and 20 seconds. This will give you enough voice data and is not too long for participants.
Remember that copyright issues also apply to images. Always keep a note of the source of your images and make sure you have the right permissions to use them in your project.
### Quality assurance
Take a look through the responses you get from your image prompts at regular intervals. If some images always seem to produce very short, confused, or awkward responses, you may need to replace them. Choose alternatives that get better results.
[^1]: **Voice data:** Audio recordings of human speech. These recordings capture the acoustic features of spoken language, such as pronunciation, speaking patterns, and rhythm.
[^2]: **Read prompt:** A sentence that contributors read aloud from a written prompt. These sentences will give you controlled samples of speech.
# 4.6 Guidelines for creating spontaneous speech prompts
While image-based prompts focus on descriptions, free-form text prompts expand your collection of [voice data](#user-content-fn-1)[^1] to include storytelling, opinions, and explanations. These prompts allow you to record conversational patterns and a range of speech styles, not just simple descriptions.
### Designing effective prompts
Create open-ended prompts that will get detailed responses of around 10-20 seconds. You need questions or instructions that invite contributors to share their experiences, opinions, or knowledge about their community. You are not asking for facts that might lead to short, limited answers.
Good spontaneous speech[ prompts](#user-content-fn-2)[^2] focus on topics that people in the target communities are familiar with, such as:
* local traditions and cultural practices
* personal likes and dislikes, and experiences
* opinions about changes in the community
* descriptions of everyday activities
For example, "Describe your favorite traditional dish and how to make it" or "Tell me about an important celebration in your community". These prompts will get rich, natural responses.
### A wide range of content
Vary the topics you use for your prompts to get different speech styles—storytelling, descriptions, instructions, and opinions. This will help you to create a more robust voice dataset[^3] that can be used for various applications. Include prompts that relate to the local area and culture. This will make doing the recording more interesting and relevant for contributors.
Avoid content that is too complex, abstract or sensitive such as political opinions, religious matters, or private questions. Focus on easier topics that most contributors feel happy to talk about.
Here are a few examples of spontaneous speech prompts:
| Talk about your favorite traditional dish and how to prepare it. If you're not sure how to make it, just tell us the ingredients. Tell us about the occasions when people cook it. |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Tell me about an important festival or celebration in your community. You can say what it's called, when you celebrate it and what people do. |
| What changes have you noticed in your town/village over the last 10 years? |
| Imagine someone stops you on the road in your town/village and asks you how to get to Maidiguri. Tell him how to get there to the best of your knowledge. If you’re not sure, you can just say you don't really know and take him to someone that can help. |
| Tell us about your job. Describe a typical day for someone doing your job. |
| A stranger stops you near your home and asks how to get to the nearest health clinic or hospital. Give them directions, pointing out any landmarks or important details. |
| Tell us what you think about the education system in your region. |
| How do people celebrate weddings in your community? |
| Tell us about a popular game or sport played in your area |
| Do you think it’s important to preserve local languages and traditions? |
| How do men usually dress in your town? What kind of clothing or jewelry is typical for your region? |
\
[^1]: **Voice data:** Audio recordings of human speech. These recordings capture the acoustic features of spoken language, such as pronunciation, speaking patterns, and rhythm.
[^2]: **Free-form prompts:** Open-ended questions or instructions that result in natural, free speech.
[^3]: **Dataset:** A collection of information that has been organized for use. A **voice dataset** is a collection of voice recordings (paired with transcription) with additional information (meta data) such as gender, age of the person recording to give more information on how the data set is constructed and to avoid bias. It is for use in research and for training or improving voice models.
# 5. Recording and validation
#### Chapter 5 overview:
{% hint style="info" %}
This chapter is for anyone working on voice data projects. This may be with TWB Voice or any other platform. We explain the key principles for creating high-quality data sets.
We cover topics such as:
* How to collect high-quality recordings
* How to rate (validate) recordings in a fair and consistent way
* Checklists so you can be more efficient and get good-quality recordings
* Making sure your recordings are in line with TTS or ASR goals
Note: This section is all about action. You don’t need to be a technical expert. We focus on being clear, consistent and fair.
{% endhint %}
Recording and validation are the two key tasks in [voice data collection](#user-content-fn-1)[^1]. To get high-quality voice datasets[^2], you need clear, varied, natural recordings. And you need to rate them with accurate validation. This will make sure they can be used to train voice technologies like [Automatic Speech Recognition (ASR)](#user-content-fn-3)[^3] and [Text-to-Speech (TTS)](#user-content-fn-4)[^4] systems. Experts may also use the datasets you create for research or to develop other models[^5].
In this section, we go through the guidelines, processes, roles, and checks that are needed during a [TWB Voice](#user-content-fn-6)[^6] project. They ensure that the data is of a good quality and consistent. We also look at the key standards and approaches that you can use to collect data and create data sets. You can use these for any project to collect data, not just on TWB Voice, but also on other platforms.
[^1]: **Voice data collection:** Gathering recordings of speech with their transcriptions in a systematic and ethical way. Also involves collecting demographic data (age, gender, accent) and for Automatic Speech Recognition should include a range of speakers. The voice data is used in research and for training or developing voice language models.
[^2]: **Dataset:** A collection of information that has been organized for use. A **voice dataset** is a collection of voice recordings (paired with transcription) with additional information (metadata) such as gender, age of the person recording to give more information on how the data set is constructed and to avoid bias. It is for use in research and for training or improving voice models.
[^3]: **Automatic Speech Recognition (ASR) or Speech-to-Text (STT):** ASR converts spoken language into text. It can be used in voice assistants and transcription services, for example. You may hear both terms, ASR and STT, and they are almost the same. But STT can be a semi-manual process, while ASR is fully automated. ASR is like a smart listener that turns spoken words into written text on your device. While it does create the text automatically, it often needs some human input to make sure everything is correct, it can make mistakes especially in languages that are less used in the digital space.
[^4]: **Text-to-Speech (TTS):** Technology that converts written text into spoken language. It can also generate audio speech. You can find TTS in accessibility tools like screen readers and in virtual assistants. It brings written texts to life through spoken words. If your phone reads out the messages you get, or an audiobook tells you your favorite story, this is because of TTS technology.
[^5]: **Model:** A computer-based system that has made use of data to learn patterns. It can make predictions or generate language. In speech technology, models use voice data to learn to recognize speech (converting audio to text) or to create speech (converting text to audio).
[^6]: **TWB Voice:** A platform for collecting voice data. It was developed by CLEAR Global, who also own it. Users can make voice recordings to help with active data collection projects in TWB Voice by [signing up to the TWB Community](https://translatorswithoutborders.org/join-the-twb-community/). The main goal of TWB Voice is to help to develop voice technology for speakers of marginalized languages. For example, by creating the voice datasets that are needed to build language models for TTS and ASR.
# 5.1 Guidelines for recording
In voice recording, contributors read out short, written prompts. Or in some cases, they speak freely. We have developed some guidelines for the projects in [TWB Voice](#user-content-fn-1)[^1].
* **Natural speech:** Try to get contributors to speak naturally, as they would in a conversation. But they also need to speak clearly.
* **Quiet setting:** Do the recordings in a quiet space, with no loud background noise (a little noise is ok). Try not to have any other people speaking or any music or other sounds.
* **Proper speed and clear speech:** Ask contributors to speak at a moderate speed and to speak clearly but naturally. It's a good idea to set a limit in seconds for each prompt
* **Avoid false starts or trailing off:** Some recordings may have sentences that are not finished or that include hesitation. Ask the speakers to record them again.
* **Position of microphone:** The microphone should not be too close to the contributor’s mouth, and not too far away either. This will help you to get a good-quality recording with no sound distortion.
{% hint style="info" %}
These guidelines are based on benchmarks from voice data projects outside of TWB Voice, including Mozilla Common Voice, NaijaVoices, and RESPIN in India. The guidelines aim to be short, clear, and concise, providing contributors with a simple but accurate framework to guide their recordings.
{% endhint %}
[^1]: **TWB Voice:** A platform for collecting voice data. It was developed by CLEAR Global, who also own it. Users can make voice recordings to help with active data collection projects in TWB Voice by [signing up to the TWB Community](https://translatorswithoutborders.org/join-the-twb-community/). The main goal of TWB Voice is to help to develop voice technology for speakers of marginalized languages. For example, by creating the voice datasets that are needed to build language models for TTS and ASR.
# 5.2 Guidelines for validation
Validation is the process where another contributor (not the speaker) listens to the voice sample to check the quality.
In [TWB Voice](#user-content-fn-1)[^1], this is a separate step from recording. It has its own guidelines. The contributor can approve or reject the voice sample. The reasons for this will be as follows:
* **Approve** (Pass) - if a recording is clear, matches the prompt, and meets quality standards - a clear voice, no slurring, mumbling, or rushing.
* **Reject** (Fail) - if a recording has major issues. For example, it includes offensive language, or some words are missing (if it’s based on a prepared prompt). There may also be loud background noise, unclear speech, or several voices.
A user can also **report a recording**. They can do this if the content is unacceptable or the language is incorrect. It may be very unclear so you can’t understand it. Reporting is like a feedback mechanism. It helps to improve the process and the platform itself.
[^1]: **TWB Voice:** A platform for collecting voice data. It was developed by CLEAR Global, who also own it. Users can make voice recordings to help with active data collection projects in TWB Voice by [signing up to the TWB Community](https://translatorswithoutborders.org/join-the-twb-community/). The main goal of TWB Voice is to help to develop voice technology for speakers of marginalized languages. For example, by creating the voice datasets that are needed to build language models for TTS and ASR.
# 5.3 Language Leads and spot checking
[Spot checking](#user-content-fn-1)[^1] is another quality control step. You can use it to make sure that broader problems are not missed, and to correct common mistakes. There are various ways of doing spot checking. The most important thing is that the person doing it is qualified to make decisions on the quality of the recording. They should be an expert in the language you are recording.
In the [TWB Voice ](#user-content-fn-2)[^2]project, we used experienced contributors and experts for this role. We called them [Language Leads](#user-content-fn-3)[^3] (LLs). They helped us to ensure good quality and to work well with the community. The LLs took on the following tasks:
* Doing spot checks, by checking selected recordings and validations at regular intervals. These were picked at random. Their aim was to ensure consistency.
* Giving feedback and help to contributors, and answering questions. Keeping the community involved.
* Helping to solve problems when contributors had issues.
* For the TWB Voice project, the LLs had a key role. They created prompts and helped to get people in the community involved as voice contributors.
These are just some of the possible tasks of an LL. It’s good to use someone from the community who understands the process and can speak the languages. They can manage community involvement and make sure the data sets are of a good quality. They can find issues early and step in to help if there are any challenges.
[^1]: **Spot checking:** Random checking of recordings/ratings to make sure they are consistent.
[^2]: **TWB Voice:** A platform for collecting voice data. It was developed by CLEAR Global, who also own it. Users can make voice recordings to help with active data collection projects in TWB Voice by [signing up to the TWB Community](https://translatorswithoutborders.org/join-the-twb-community/). The main goal of TWB Voice is to help to develop voice technology for speakers of marginalized languages. For example, by creating the voice datasets that are needed to build language models for TTS and ASR.
[^3]: **Language Leads (LLs):** Language experts with lots of experience. They can do spot checks to ensure quality and can give feedback.
# 5.4 Checklists before recording
To make sure things go well, we have made a shorter version of the guidelines to give to contributors just before they start recording. This helps them to get ready for their task. It also helps with data quality and means you can spend less time on rating[^1] or doing quality checks. Here is an example of a checklist:
* [ ] Is the device fully charged? Is it working properly?
* [ ] Are you in a quiet place where you won’t get interrupted?
* [ ] Are you using headphones or a good microphone?
* [ ] Do you have the right microphone permissions for your browser and phone?
* [ ] Are you logged in? Are you familiar with the platform?
* [ ] Have you read through the recording guidelines? Have you got answers to any questions you had?
You can add this checklist to your onboarding materials. You could also use it as a pop-up reminder on the platform. This should help with consistency and reduce errors.
[^1]: **Rating:** An individual quality assessment by a contributor. They either approve or reject a piece of language data (recording in the case of voice data) and base their rating on the pass/fail guidelines. Several ratings may be needed to decide whether this data has passed or failed for quality.
# 5.5 TTS versus ASR-oriented recording
[Voice data](#user-content-fn-1)[^1] can be used for different types of [language technology](#user-content-fn-2)[^2]. For [TWB Voice](#user-content-fn-3)[^3], it was helpful to understand the goal of the dataset[^4] (building TTS[^5] or ASR[^6]). We could then adapt our recording instructions and our criteria for validation.
### Text-to-Speech (TTS)
TTS models[^7] convert text into speech that sounds like a human. These models need a balanced dataset and the voices should be even and clear. Recordings must:
* be neutral and have a consistent tone
* use standard pronunciation and a normal speed of speaking
* avoid emotion and dramatic speech, and irregular speech patterns
* be done in a controlled space with no background noise, following strict quality instructions
### Automatic Speech Recognition (ASR)
ASR models convert spoken language into written text. For ASR, recordings should:
* be as natural and varied as possible, just like real-life conversations
* include lots of different accents, speeds, and genders
* include many types of speaker (age, gender, region)
| **Key takeaway** |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
High-quality recordings and fair validation will give you usable and high-quality voice datasets.
Use clear guidelines and checklists. Make sure your recordings match the goals of your project.
|
[^1]: **Voice data:** Audio recordings of human speech. These recordings capture the acoustic features of spoken language, such as pronunciation, speaking patterns, and rhythm.
[^2]: **Language Technology (LT):** Technologies that focus on human language, including both spoken and written language. They can process, understand, and generate language. Examples are the tools on your phone or computer that understand and generate words, like translation apps or voice assistants. They allow us to communicate and interact with our devices with language. When you talk to a virtual assistant like Siri or Alexa, or your phone suggests the next word in a message, that’s because of language technology. It makes technology more accessible and user-friendly.
[^3]: **TWB Voice:** A platform for collecting voice data. It was developed by CLEAR Global, who also own it. Users can make voice recordings to help with active data collection projects in TWB Voice by [signing up to the TWB Community](https://translatorswithoutborders.org/join-the-twb-community/). The main goal of TWB Voice is to help to develop voice technology for speakers of marginalized languages. For example, by creating the voice datasets that are needed to build language models for TTS and ASR.
[^4]: **Dataset:** A collection of information that has been organized for use. A **voice dataset** is a collection of voice recordings (paired with transcription) with additional information (metadata) such as gender, age of the person recording to give more information on how the data set is constructed and to avoid bias. It is for use in research and for training or improving voice models.
[^5]: **Text-to-Speech (TTS):** Technology that converts written text into spoken language. It can also generate audio speech. You can find TTS in accessibility tools like screen readers and in virtual assistants. It brings written texts to life through spoken words. If your phone reads out the messages you get, or an audiobook tells you your favorite story, this is because of TTS technology.
[^6]: **Automatic Speech Recognition (ASR) or Speech-to-Text (STT):** ASR converts spoken language into text. It can be used in voice assistants and transcription services, for example. You may hear both terms, ASR and STT, and they are almost the same. But STT can be a semi-manual process, while ASR is fully automated. ASR is like a smart listener that turns spoken words into written text on your device. While it does create the text automatically, it often needs some human input to make sure everything is correct, it can make mistakes especially in languages that are less used in the digital space.
[^7]: **Model:** A computer-based system that has made use of data to learn patterns. It can make predictions or generate language. In speech technology, models use voice data to learn to recognize speech (converting audio to text) or to create speech (converting text to audio).
# 6. Community engagement
#### Chapter 6 overview:
{% hint style="info" %}
This chapter is for project managers and community engagement officers. It’s also for anyone who is trying to get communities involved in collecting voice data.
We will cover how to:
* find the right contributors
* onboard contributors
* keep them involved over time
* motivate users with ethical methods
* use feedback to keep people involved
Note: This section is practical. You don’t need any technical skills.
{% endhint %}
Community engagement means the process of getting speakers of marginalized languages involved in your project. They then contribute data that will later be used to build [language technology](#user-content-fn-1)[^1]. It will also be used for research, training and even to assess existing language models and AI.
For [TWB Voice](#user-content-fn-2)[^2], this process was the key to success for [voice data collection](#user-content-fn-3)[^3] and validation. In this section, we share our learnings and the approaches that we tested in the TWB Voice project. We offer practical help with finding, onboarding and supporting [community members](#user-content-fn-4)[^4] and keeping them involved so we can collect as much [voice data](#user-content-fn-5)[^5] as possible.
[^1]: **Language Technology (LT):** Technologies that focus on human language, including both spoken and written language. They can process, understand, and generate language. Examples are the tools on your phone or computer that understand and generate words, like translation apps or voice assistants. They allow us to communicate and interact with our devices with language. When you record a message and the device transforms it into text, or your phone suggests the next word in a message, that’s because of language technology. It makes digital tools more accessible, interactive and sometimes more efficient.
[^2]: **TWB Voice:** A platform for collecting voice data. It was developed by CLEAR Global, who also own it. Users can make voice recordings to help with active data collection projects in TWB Voice by [signing up to the TWB Community](https://translatorswithoutborders.org/join-the-twb-community/). The main goal of TWB Voice is to help to develop voice technology for speakers of marginalized languages. For example, by creating the voice datasets that are needed to build language models for TTS and ASR.
[^3]: **Voice data collection:** Gathering recordings of speech with their transcriptions in a systematic and ethical way. Also involves collecting demographic data (age, gender, accent) and for Automatic Speech Recognition should include a range of speakers. The voice data is used in research and for training or developing voice language models.
[^4]: **Community members:** People at the center of a project who contribute by recording and validating data. In this context, community refers to their shared interest in contributing to data collection and the languages they speak. Community members are well positioned to provide feedback on linguistic aspects and offer input on the project's direction and needs.
[^5]: **Voice data:** Audio recordings of human speech. These recordings capture the acoustic features of spoken language, such as pronunciation, speaking patterns, and rhythm.
# 6.1 Identifying contributor profiles
For effective community engagement, you first need to understand who is best suited to contribute. You can start by analyzing the capacity of contributors who have offered to help. For the [TWB Voice](#user-content-fn-1)[^1] projects in Hausa, Kanuri and Shuwa Arabic, we looked at the existing group of volunteers (linguists who had helped [Translators Without Borders](#user-content-fn-2)[^2] with translations over the years) and identified a number of key profiles. Here are some of the characteristics that we found to be very important:
* Speakers of the [target languages](#user-content-fn-3)[^3] (dialect and other language features must match the goal of the project)
* They should have basic digital literacy (able to use mobile or web platforms).
* Community influencers — teachers, local partners, and language group leaders. These people play a key role in getting people to help collect data for [low-resource languages](#user-content-fn-4)[^4]. If you organize contributors into language groups, they work better and have a sense of belonging. It motivates them if they are part of a group effort.
* Experienced linguists ([Language Leads](#user-content-fn-5)[^5]) are useful for difficult tasks like prompt creation and validation. We found that using Language Leads helped to get people in the community involved in data collection.
* We motivated contributors by recognition, certificates, and sharing messages about the positive impact of their work.
We used the following workflow to find the right [contributor profiles](#user-content-fn-6)[^6]:
* Identify native speakers of the target language(s) (to match the goals of the project).
* Share information about the data collection project. Use clear messaging on the tasks involved, the reason for the project, and how important their help would be.
* If there is a [recognition program](#user-content-fn-7)[^7] in place, share details early on. Make it easy for contributors to access.
* Send out invitations to join. Include direct links and instructions on how to join the project.
[^1]: **TWB Voice:** A platform for collecting voice data. It was developed by CLEAR Global, who also own it. Users can make voice recordings to help with active data collection projects in TWB Voice by [signing up to the TWB Community](https://translatorswithoutborders.org/join-the-twb-community/). The main goal of TWB Voice is to help to develop voice technology for speakers of marginalized languages. For example, by creating the voice datasets that are needed to build language models for TTS and ASR.
[^2]: **Translators without Borders (TWB):** A part of CLEAR Global, a non-profit organization that helps people to get information and have a voice, whatever language they speak.
[^3]: **Target language:** The language(s) for which you are collecting the voice data.
[^4]: **Low-resource language:** A language that has limited written or recorded materials and is rarely found in digital tools, data, or technology. This means that technologies like speech recognition or machine translation are not available for the language and are difficult to build. This may be due to a lack of written content, digital resources (like websites or videos), or support from organizations that develop language technology.
[^5]: **Language Leads (LLs):** Language experts with lots of experience. They can do spot checks to ensure quality and can give feedback.
[^6]: **Contributor profiles**: Types of people who are suitable for making recordings when you are collecting voice data. They may be native speakers, bilingual people or linguists.
[^7]: **Recognition program**: A system of rewards (points, certificates, or money) to motivate contributors and acknowledge the importance of their efforts.
# 6.2 Guidelines for onboarding
Onboarding shapes the whole experience for contributors. In [TWB Voice](#user-content-fn-1)[^1], we used an onboarding process that has a clear structure but is also flexible. It includes:
* **Self-guided onboarding screens:** Contributors can go straight to the onboarding materials on the platform. This means they can get started easily and at their own pace.
* **Live onboarding sessions:** We organize in-person activities where [Language Leads](#user-content-fn-2)[^2] show new people how to use the platform. We also use WhatsApp groups for real-time Q\&As. These provide a quick and easy way to get answers and help when learning about the platform.
* **Task guidelines:** The platform includes clear task guidelines that are easy to understand. We ask contributors to read these guidelines before they set up an account. This makes sure that they understand the tasks before starting.
* **Terms and conditions:** During the onboarding process, we show contributors the terms and conditions, including [consent forms](#user-content-fn-3)[^3]. They must read these through and give their consent before they are allowed to take on any tasks. They can do this by scrolling down as they read the consent form. They can only move on when they have read it through.
[^1]: **TWB Voice:** A platform for collecting voice data. It was developed by CLEAR Global, who also own it. Users can make voice recordings to help with active data collection projects in TWB Voice by [signing up to the TWB Community](https://translatorswithoutborders.org/join-the-twb-community/). The main goal of TWB Voice is to help to develop voice technology for speakers of marginalized languages. For example, by creating the voice datasets that are needed to build language models for TTS and ASR.
[^2]: **Language Leads (LLs):** Language experts with lots of experience. They can do spot checks to ensure quality and can give feedback.
[^3]: **Consent form:** A document that voice contributors are presented with before they start recording. It explains how their data will be collected and used. If they agree to the terms and sign the form, they can begin contributing. The consent form helps ensure that contributors understand any risks, know their rights, and can make an informed choice about sharing their voice data.
# 6.3 Approaches to community engagement
To build and maintain energy in the community during data collection, you need to develop approaches that are continuous, focused and intentional. Key approaches included:
* **Creating vibrant spaces for communication:** We used WhatsApp groups for daily updates, shout-outs, solving problems, and sharing good news.
* **Running special events:** For example, data collection marathons, meaning periods of intense data collection. We used leaderboard[^1] challenges to create the hype, and themed weeks to get more people to join us.
* **Localizing communication:** We used language that people could relate to in our messages, showing respect for local culture and language differences. We draft a standard message first, then the [Language Leads](#user-content-fn-2)[^2] adapt it and add some bits of local language.
* **Direct, human support:** Language Leads acted as first points of contact to increase trust and answer any questions. This is a tried and tested approach.
* [**Data incentives**](#user-content-fn-3)[^3]**:** As well as giving recognition points that people could collect and swap for money, we noticed that the cost of data is high in low-resource settings. So we offered data incentives and this helped to increase levels of engagement.
[^1]: **Leaderboard:** A table view that displays the performance of all contributors and allows them to compare how well they are doing against others in real time.
[^2]: **Language Leads (LLs):** Language experts with lots of experience. They can do spot checks to ensure quality and can give feedback.
[^3]: **Data incentive:** This means giving internet data to certain contributors to motivate them. They will then hopefully deliver more tasks.
# 6.4 Strategies to keep people involved
It’s easy to get people to help short-term, but harder to get long-term commitment. In [TWB Voice](#user-content-fn-1)[^1], we used the following strategies:
* **Recognition as well as rewards:** Acknowledging people’s help in public, and not just at payout stages. Each day and even week, we send out a message about our data collection milestones, and set targets for the day/week. This gives contributors something to look forward to.
* **The chance to progress:** Allowing active contributors to move up to the role of “trusted linguists". This means they can do validation and not just recording. People who contribute more and reach certain thresholds become trusted linguists. This motivates them to do more.
* **Transparent communication:** Regular updates about the impact of the project, progress towards goals, and future opportunities.
* **Flexible task structures:** Allowing contributors to move between recording and validation to help prevent tiredness. You need to be careful with this and perhaps check on the output of certain individuals.
[^1]: **TWB Voice:** A platform for collecting voice data. It was developed by CLEAR Global, who also own it. Users can make voice recordings to help with active data collection projects in TWB Voice by [signing up to the TWB Community](https://translatorswithoutborders.org/join-the-twb-community/). The main goal of TWB Voice is to help to develop voice technology for speakers of marginalized languages. For example, by creating the voice datasets that are needed to build language models for TTS and ASR.
# 6.5 Frameworks for engagement and feedback
With data collection, we found it important to have structured ways of giving feedback. This helped us to improve the way we worked:
* **Listening:** Check-in emails from time to time to ask contributors about their concerns, ideas, and experiences. Also ask about certain features and data collection processes.
* **Responding quickly:** Sorting out technical issues, answering questions, and replying to suggestions showed respect for contributors’ time and effort. We deal with questions we receive via the “contact us” form as soon as we receive them.
* **Step-by-step improvements:** We always made sure to use the feedback we collected. It helped to shape changes in platform features, instructions, and strategies.
# 6.6 Recognition
It’s very important to recognize and appreciate the time and effort of contributors. This makes the community engagement fair and ethical, and motivates contributors.
1. **Points-based recognition program**\
Contributors earn points for the tasks they complete. These points lead to certificates of appreciation and, if they get to certain thresholds, to monetary rewards. The points system is a recommended best practice from similar projects and ensures fairness, competition, and motivation.
2. **Leaderboards**\
Leaderboards[^1] can be a powerful tool for engagement. They offer real-time recognition. Contributors can see how well they have performed compared to others. This motivates them to continue the work and also gives them public recognition.
3. **Inclusive recognition model**\
You need to make sure that it’s not only top performers who are treated fairly and gain recognition. Contributors get rewards at various thresholds, based on how much they do. So even lower-volume contributors have the chance to get some positive recognition. This model makes sure that everyone feels valued for their efforts.
4. **Celebration moments**\
We regularly celebrated milestones and top contributors, and recognized "Voice Stars". This helped to create a positive sense of community. Some people had joined the project because they saw an opportunity for visibility and to earn respect. So highlighting their achievements in this way was a game-changer.
5. [**Data incentives**](#user-content-fn-2)[^2]\
In voice recording, the amount of data people use may be higher. If you identify the most suitable network of contributors and then issue data to them, it will help them to deliver more tasks.
| **Key takeaway** |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| A community engagement model that is structured, respectful, and localized is very important when expanding the collection of voice data. So NEVER skip onboarding, recognition, or ongoing support. |
[^1]: **Leaderboard:** A table view that displays the performance of all contributors and allows them to compare how well they are doing against others in real time.
[^2]: **Data incentive:** This means giving internet data to certain contributors to motivate them but also to ensure contributors have the required data to share their voice recordings over the internet.
# 7. Responsible data management and protection
#### Chapter 7 Overview:
{% hint style="info" %}
In this chapter, we explain how CLEAR Global manages the collection of voice data. We also look at the steps it takes to make sure users know how CLEAR Global uses their data and what their rights are so they have control of their data. It is a useful guide for internal teams and external reviewers as it explains contributor consent, data protection, and legal compliance.
For this section of the playbook, you need to have an understanding of data protection regulations, meaning the GDPR. You also need some knowledge of database structures. But we have tried to keep things simple and focus on the rights of users. Consent and licensing are very important when collecting data. This section aims to help organizations deal with them and comply with the GDPR.
{% endhint %}
Collecting [voice data](#user-content-fn-1)[^1] can be difficult to organize and manage. There are also a number of important legal issues to consider. You are not allowed to collect personal data (including voice data) without the informed consent of the contributor. And you should store and use data responsibly. In this section, we look at how CLEAR Global manages consent and privacy when collecting data. We also look at the steps it takes to make sure users understand how CLEAR Global uses their data and what rights they have over the use of their data.
[^1]: **Voice data:** Audio recordings of human speech. These recordings capture the acoustic features of spoken language, such as pronunciation, speaking patterns, and rhythm.
# 7.1 Data storage
### Data flow
Currently, all [TWB Voice](#user-content-fn-1)[^1] users have to first sign up to TWB Platform. This is a platform that TWB developed for our community of linguists to use. They use it to take on translation jobs and for other language services too. Users have to accept the [terms and conditions](https://twbplatform.org/static/terms/) and [privacy policy](https://twbplatform.org/static/privacy/).
Once they have agreed and signed up to TWB Platform, contributors can also log into TWB Voice. They can use the same login credentials (email and password).
When they log in for the first time, they will need to accept some extra terms. These apply to the collection of voice data:
* [Consent to participate in TWB Voice initiative](https://twbvoice.org/consent)
* [Code of conduct](https://twbvoice.org/policy)
New users will also have to provide some further information. This information is relevant to the collection of voice data: gender, year of birth, education level, and language variant.
All of the data we collect is stored securely across multiple CLEAR Global databases.
When they have done this, users can start doing TWB Voice tasks. The tasks they can do will depend on their level of access.
### Data segregation
* We store personal information of users (name, email, gender, year of birth, education level, and language variant) separately from the user recordings. This means there is no risk that people could find out the identity of the speakers.
* We only add the user metadata[^2] (gender, year of birth, education level, and language variant) to the recording when we export the data. We never share the user’s name or email in the published dataset[^3].
* We collect recordings for [Automatic Speech Recognition (ASR)](#user-content-fn-4)[^4] models through specific workflows. We store them in separate datasets from recordings for Text to Speech (TTS) models. We do this because we don’t publish TTS datasets fully, but use them internally to train models. We publish a partial set within the ASR dataset so that users can be anonymous.
### **Systems for storing and securing data**
We store all voice recordings and metadata on secure servers. CLEAR Global manages and approves these servers. Our infrastructure ensures:
* **user-based access control**, so access depends on the role of the user (e.g. reviewers, admins)
* **strong password and device policies** are in place across all accounts
* **data encryption** so that unauthorized persons cannot access or change the data
* **automated and encrypted backups** on a regular schedule
* **server hardening and monitoring** (firewall, operating system patches, minimal access configurations)
* **event logging** to detect any unusual activity or misuse
[^1]: **TWB Voice:** A platform for collecting voice data. It was developed by CLEAR Global, who also own it. Users can make voice recordings to help with active data collection projects in TWB Voice by [signing up to the TWB Community](https://translatorswithoutborders.org/join-the-twb-community/). The main goal of TWB Voice is to help to develop voice technology for speakers of marginalized languages. For example, by creating the voice datasets that are needed to build language models for TTS and ASR.
[^2]: **Metadata:** Extra information that gives some background to a dataset or parts of a dataset. Examples are demographics of the speakers (age, gender, accent), recording conditions (microphone type, level of background noise), or language-related details (dialect, speed of speaking, emotional tone).
[^3]: **Dataset:** A collection of information that has been organized for use. A **voice dataset** is a collection of voice recordings (paired with transcription) with additional information (metadata) such as gender, age of the person recording to give more information on how the data set is constructed and to avoid bias. It is for use in research and for training or improving voice models.
[^4]: **Automatic Speech Recognition (ASR) or Speech-to-Text (STT):** ASR converts spoken language into text. It can be used in voice assistants and transcription services, for example. You may hear both terms, ASR and STT, and they are almost the same. But STT can be a semi-manual process, while ASR is fully automated. ASR is like a smart listener that turns spoken words into written text on your device. While it does create the text automatically, it often needs some human input to make sure everything is correct, it can make mistakes especially in languages that are less used in the digital space.
# 7.2 Legal issues: contracts, data protection, intellectual property
### **Data protection framework**
[CLEAR Global](#user-content-fn-1)[^1] complies with the EU [General Data Protection Regulation](#user-content-fn-2)[^2] (GDPR).
We act as a [data controller](#user-content-fn-3)[^3] for internal systems and we carefully check all third-party processors that we use for storing data and analysis.
Voice recordings count as personal data—even if they are anonymized and don’t include any other information. This is because they may reveal personal details about the speaker, such as gender, age, or where they come from.
Under the GDPR, key terms apply:
* Personal data includes voice recordings and metadata[^4]
* Anyone who processes the data acts as an independent data controller
* Wherever the users live, they have the right to:
* know what personal information is stored about them
* object to how their personal information is being processed and ask for correction or deletion of their data
* ask for a copy of their personal data in a format that allows them to transfer it to another organization
### **Dataset sharing agreements**
Persons or organizations who want to have access to the datasets[^5] must:
* sign the **Dataset Access Terms** which state that they are **independent data controllers**
* agree that they will:
* comply with the GDPR and other relevant laws. This means they must secure the data and respect the rights of contributors.
* only process the data for the purpose of training[^6] ASR models.
* respond to any requests for access to data or deletion.
* notify CLEAR Global of any breach or misuse of data.
### **Intellectual property**
Contributors will still have moral rights over their voice recordings. This means their personal right to be credited for their work and to prevent harmful changes to their work. These rights are separate from copyright. Contributors cannot give them up or pass them on to someone else, even if they can do this for economic rights (e.g. licensing). They include:
* the right to be credited as the author of the work (right of attribution)
* the right to say no to harmful changes or misuse of the work that could damage the creator's reputation (right of integrity)
* the right to remove or take back a work
### **Data retention and deletion**
* We only keep data for as long as we need it to review, improve, or publish it.
* If a contributor **takes back their consent**, we:
* remove their contributions from our internal systems
* mark their data and leave it out of future dataset releases
* contact known dataset downloaders and tell them that the person has taken back (withdrawn) their consent
* We do **not keep archived versions** of public datasets that contain withdrawn data.
[^1]: **CLEAR Global:** A non-profit organization that helps people to get information and be heard, whatever language they speak. [Translators without Borders](https://clearglobal.org/translators-without-borders/) is a part of CLEAR Global.
[^2]: **The General Data Protection Regulation (GDPR):** A European Union law that deals with personal data. It tells us how to collect, process, store, and share data. It makes sure people have control over their personal data. It also ensures that organizations handle such data in a transparent, secure, and lawful way.
[^3]: **Data controller:** An individual or organization that is responsible for processing personal data. They decide why and how they will process the data. The General Data Protection Regulation states that data controllers have to make sure that data processing is lawful, transparent, and secure. They also have to respect the rights of the people whose data they process.
[^4]: **Metadata:** Extra information that gives some background to a dataset or parts of a dataset. Examples are demographics of the speakers (age, gender, accent), recording conditions (microphone type, level of background noise), or language-related details (dialect, speed of speaking, emotional tone).
[^5]: **Dataset:** A collection of information that has been organized for use. A **voice dataset** is a collection of voice recordings (paired with transcription) with additional information (metadata) such as gender, age of the person recording to give more information on how the data set is constructed and to avoid bias. It is for use in research and for training or improving voice models.
[^6]: **Training:** Teaching a computer-based model to recognize patterns. To do this, you need to show it large amounts of data as examples.
# 7.3 Informed consent
### **Getting people’s consent**
The consent model uses a two-step method to get informed consent:
1. **Registration on TWB Platform:** Users agree to [standard terms](https://twbplatform.org/static/terms/) and [privacy policy](https://twbplatform.org/static/privacy/).
2. **TWB Voice onboarding:** Users have to accept the [TWB Voice](#user-content-fn-1)[^1] [Consent Form](https://twbvoice.org/consent). This explains:
* how we will use their [voice data](#user-content-fn-2)[^2]
* the review and quality control processes
* their rights to have data deleted and to take back consent
### **Quality review**
To ensure ethical use of the data and make sure it isn’t harmed or changed:
* Ask trained community reviewers or in-house [Language Leads](#user-content-fn-3)[^3] to check and approve each recording.
* Give reviewers clear criteria for approval or rejection. These should include clear audio, accurate language and compliance with the [Code of Conduct](https://twbvoice.org/policy). You can find more details in the [“Recording and Validation” section](/5.-recording-and-validation).
* If they find language that goes against the code of conduct, users can report it. We have clear processes to deal with these reports. We also explain what will happen if we confirm the abuse (data deletion, user suspended, etc.).
### **Rights and redress**
Contributors can contact CLEAR Global at any time to:
* ask to have their data deleted
* ask for information on downloads of their data
* make a complaint or ask for corrections if there is a breach of their rights under the GDPR.
[^1]: **TWB Voice:** A platform for collecting voice data. It was developed by CLEAR Global, who also own it. Users can make voice recordings to help with active data collection projects in TWB Voice by [signing up to the TWB Community](https://translatorswithoutborders.org/join-the-twb-community/). The main goal of TWB Voice is to help to develop voice technology for speakers of marginalized languages. For example, by creating the voice datasets that are needed to build language models for TTS and ASR.
[^2]: **Voice data:** Audio recordings of human speech. These recordings capture the acoustic features of spoken language, such as pronunciation, speaking patterns, and rhythm.
[^3]: **Language Leads (LLs):** Language experts with lots of experience. They can do spot checks to ensure quality and can give feedback.
# 7.4 Downloading data for publishing: criteria for recordings and fields included
### **Criteria to include a recording**
There are two approaches to publishing data. The first approach is that only recordings that have:
* gained approval through the review process
* passed quality checks for content and technical issues
* got the right consent
…can be included in datasets for the public to download.
The second option is to publish all the recordings that have got the right consent, but split them into subsets of “approved”, “rejected”, and “pending review”.
For the current project, we have followed the second approach.
### **Published metadata fields**
Each recording includes anonymized metadata[^1] that lists: language, language variant, year of birth, country, gender, and education level
{% hint style="info" %}
Public releases do not contain anything that could identify a particular person (names, emails, usernames).
{% endhint %}
### **Dataset access and licensing**
* All public datasets are hosted in [**gated repositories**](https://huggingface.co/datasets/CLEAR-Global/TWB-Voice-1.0) on [Hugging Face](https://huggingface.co). This ensures proper approval of the Dataset Access Terms. It also allows us to track downloads.
* We deal with any requests for deletion quickly. We tell people who downloaded the data if the deletions will affect shared datasets.
* We release datasets and models under a [custom license](https://huggingface.co/datasets/CLEAR-Global/TWB-Voice-dataset-access-terms/blob/main/README.md) where downloaders must accept the Dataset Access Terms first and then the dataset is provided under the terms of [CC BY-NC 4.0](https://creativecommons.org/licenses/by-nc/4.0/deed.en). This allows non-commercial use with proper crediting.
[^1]: **Metadata:** Extra information that gives some background to a dataset or parts of a dataset. Examples are demographics of the speakers (age, gender, accent), recording conditions (microphone type, level of background noise), or language-related details (dialect, speed of speaking, emotional tone).
# 8. Access to datasets and models
#### Chapter 8 overview:
{% hint style="info" %}
This section is for researchers, developers, humanitarian technology practitioners, and program managers who need to publish or access speech datasets and models.
We cover:
* how to prepare a dataset for publication: metadata, language codes, and the dataset card
* how to choose a license that fits your goals and protects your community
* how to handle gates access and data rights (including GDPR)
* where to publish: Hugging Face, Mozilla Data Collective, and other platforms
* how to publish pre-trained speech AI models.
You don’t need much technical expertise for most of this section. If you plan to use datasets and models in your own projects, some basic programming knowledge will help — especially for programmatic data access through Python libraries.
{% endhint %}
# 8.1 Preparing your dataset for publication
A published dataset is only useful if people can find it, understand it, and use it correctly. This section covers the metadata and documentation you should include so your dataset reaches the right audience and gets used as intended.
### Language identification and metadata
Every dataset needs a clear language identifier. The international standard for this is [ISO 639-3](https://iso639-3.sil.org/), which assigns a three-letter code to each language. Getting the right code right matters for two reasons. First, if a researcher is looking for datasets in your language, they search by language code — a mislabeled dataset simply won’t be found by the people who need it most. Second, automated systems — including large language models and speech processing pipelines — use these codes to route data. If you label your dataset with the wrong code, it may be picked up by a model training run and treated as a different language, which corrupts the model’s performance for both languages. Getting the code right is one of the simplest things you can do to make your dataset genuinely useful.
You can look up codes at [iso639-3.sil.org](https://iso639-3.sil.org/). The Wikipedia page for most languages also lists the ISO 639-3 code in the sidebar — a quick way to check.
| **Macro language codes vs. individual language codes** |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Some ISO 639-3 codes are “macro language” codes that cover a group of related varieties. For example, *kau* is the macro language code for Kanuri, but Central Kanuri specifically is *knc*. Similarly, Swahili has the macro code *swa*, but if you are working with Congolese Swahili — which is quite different from coastal Swahili — labeling your dataset as *swa* wouldn’t help technologists who are working specifically on the Congolese variety, which has its own code: *swc*. Whenever possible, use the most specific code that applies to your data. This helps downstream users understand exactly what variety is represented. |
Beyond the language code, include:
* **Language name and variant/dialect** — e.g. “Kanuri (Central)” or “Congolese Swahili”
* A **clear, informative description** — what the dataset contains, how it was collected, and what it is intended for. A good description helps people decide whether this dataset fits their needs before they download it.
* **Task category** — what the dataset is designed for (automatic speech recognition, text-to-speech, audio classification, etc.)
* **Domain** — the subject area the speech content covers. Speech datasets are often collected around a specific domain, such as agriculture, health, humanitarian aid, legal, or general conversation. Stating the domain helps users assess whether the vocabulary and topics in the dataset match their use case.
* **Size information** — number of hours, number of speakers, number of recordings
* **Tags** — additional keywords that help with discovery (e.g. speech, read-speech, spontaneous, the language name)
### The dataset card
A dataset card is a structured document that accompanies the dataset and describes everything a user needs to know: what the data contains, how it was collected, who contributed, how quality was controlled, and under what terms it can be used. Think of it as the dataset’s identity document.
CLEAR Global uses a standardized dataset card format for TWB Voice datasets. The [TWBVoice-data-packaging](https://github.com/translatorswb/TWBVoice-data-packaging) repository contains the tooling we use to generate cards automatically from a YAML configuration file. You can see a complete example in the [sample Kanuri dataset card](https://github.com/translatorswb/TWBVoice-data-packaging/blob/main/examples/sample-kanuri/out/kau_2026-04-23_dataset_card.md).
The table below lists the key sections of a dataset card and what to include in each:
Section
What to include
Description
A short summary of the dataset: language, size, collection method, and purpose.
Languages
ISO 639-3 code(s) and language name(s), including dialect or variant.
Dataset structure
File layout, metadata fields, and what each field means.
Statistics
Number of recordings, hours, speakers, gender/age/region breakdown.
Data collection
How the data was gathered — platform, methodology, who the speakers were.
Quality control
Validation steps: review stages, number of reviewers, rejection criteria.
Ethical considerations
Consent, anonymization, speaker rights, and any restrictions.
Usage restrictions
Forbidden uses, intended use cases, and any conditions beyond the license.
License
The license under which the data is released.
Citation
How to cite the dataset in academic work.
Contact
Who to reach for questions, data issues, or retraction requests.
Acknowledgments
Funders, partners, and communities who contributed.
Not every section applies to every dataset — the tooling only renders sections that have content. But the more complete your card is, the more trust users will place in your data.
{% hint style="warning" %} **Do not name contributors in voice datasets**
Speech is personally identifiable information — a person’s voice can be used to identify them, and voice models can be built to impersonate them. Never publish the names of individual speakers, in a dataset card, metadata, or file names. Use anonymized identifiers (such as hashed user IDs) instead. This protects contributors from potential misuse of their voice data.
{% endhint %}
### Ethical usage and considerations in the card
The dataset card is also where you communicate your expectations about how the data should — and should not — be used. This goes beyond the legal text of the license. Consider including:
* **Intended use** — What the dataset is designed for. For example: “This dataset is intended for research and development of automatic speech recognition systems for Kanuri.”
* **Forbidden uses** — Uses you explicitly do not permit or discourage. For example: speaker identification, surveillance, or any application that could harm the contributing community.
* **Data control procedures** — How a speaker can request that their recordings be removed (see [Section 8.3 on GDPR](/8.-access-to-datasets-and-models/8.3-gated-access-data-control-and-gdpr)).
* **Known limitations** — Biases in speaker demographics, recording conditions, or coverage gaps that users should be aware of.
* **Contact for issues** — A clear way for users to report problems or reach the data steward.
These sections don’t carry legal force the way a license does, but they set norms and expectations. Many responsible users — including academic researchers — will follow them.
# 8.2 Licensing your dataset
The license you choose determines who can use your data, for what purposes, and under what conditions. This is one of the most consequential decisions you’ll make when publishing a dataset, and it deserves careful thought.
Without a license, your dataset exists in a legal grey zone. In many jurisdictions, the default is “all rights reserved” — meaning nobody can legally use it. A license removes that ambiguity and tells the world what is allowed.
But licensing is not just a legal formality. It shapes who benefits from your work. A fully open license maximizes reach, but it also gives equal access to a well-funded commercial provider and a local university with limited resources. A more restrictive license protects the community’s interests but may reduce adoption. There is no universally correct answer — the right license depends on your goals, your community’s wishes, and the context.
### Common license types
License
Permits commercial use
Requires attribution
Share-alike
Notes
CC0
Yes
No
No
Public domain dedication. No restrictions at all.
CC-BY-4.0
Yes
Yes
No
Open, requires credit.
CC-BY-SA-4.0
Yes
Yes
Yes
Derivatives must use the same license.
CC-BY-NC-4.0
No
Yes
No
Non-commercial use only.
Apache 2.0
Yes
Yes
No
Common in software; includes a patent grant. Sometimes used for datasets.
OpenRAIL
Varies
Yes
Varies
Responsible AI license with behavioral-use clauses — allows broad use but restricts specific harmful applications.
For more detail on Creative Commons licenses, see [creativecommons.org/licenses](https://creativecommons.org/licenses/).
**A note on non-commercial licenses.** The “NC” (non-commercial) clause is one of the most commonly used restrictions, but its boundaries are not always clear-cut. Academic research is generally considered non-commercial, but what about a university spin-off, or an NGO that charges fees for its services? The definition of “commercial” varies by jurisdiction and context. If you choose an NC license, be prepared to answer questions from users who are unsure whether their use qualifies.
All TWB Voice datasets are currently published under **CC-BY-NC-4.0** (Creative Commons Attribution Non-Commercial). This means anyone can use the data for research, education, and non-commercial development, but commercial use requires separate permission.
| **Beyond standard licenses: community-designed alternatives** |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| The licenses above are well-established frameworks, but they are not the only options. Communities and organizations are experimenting with new licensing models tailored to the specific challenges of language data. One example is the [Nwulite Obodo Open Data License](https://licensingafricandatasets.com/) (NOODL), developed through consultation with African language communities. NOODL builds on Creative Commons (Attribution + Share-Alike) but adds a tiered framework: users in developing countries get standard open-access terms, while users in high-income countries are asked to share value or benefits back with the data community — through monetary compensation, infrastructure access, capacity building, or collaborative development. It was first applied to the [DhoNam Dholuo Speech Dataset](https://kencorpus.ke/items/d6444855-7b52-46a7-9d92-48b930b4b08e) for Dholuo, a language spoken by 5 million people in Kenya. For more on this approach, see: [\*NOODL — An experiment in equitable data licensing\*](https://openfuture.eu/wp-content/uploads/2026/04/260421_NOODL-An-innovation-in-open-data-licensing.pdf) (Alek Tarkowski, Open Future, April 2026). |
### Data sovereignty and community control
Before choosing a license, ask a fundamental question: **do you want your dataset to be sovereign?**
A sovereign dataset is one where the community retains control over who can use it and how. This is the opposite end of the spectrum from a fully open release. Both approaches have legitimate reasons behind them.
**The case for openness:** Open data accelerates research, enables collaboration, and helps build technologies for underserved languages. It lowers the barrier for anyone who wants to work on your language.
**The case for sovereignty:** Openness also gives access to commercial providers who may use your community’s language data to build products — potentially products sold back to the community, or products that don’t serve the community’s needs at all. When you release data openly, you cannot control who profits from it.
| **Case Study: Te Hiku Media and the Kaitiakitanga License** |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Te Hiku Media, a Maori media organization in Aotearoa New Zealand, developed the [Kaitiakitanga License](https://github.com/TeHikuMedia/Kaitiakitanga-License/blob/tumu/LICENSE.md) specifically to keep te reo Maori (the Maori language) data under community control. Their position: openly sharing indigenous language data risks a form of digital colonization, where outside actors extract value from cultural and linguistic resources without accountability to the community. The Kaitiakitanga License establishes principles of data guardianship and requires that benefits flow back to the data community. |
There is no single right answer. Some options in between:
* **Fully open** (e.g. CC-BY or CC0) — Maximum reach, no control over downstream use.
* **Open for non-commercial use** (e.g. CC-BY-NC) — Research and social uses are free; commercial users must negotiate separately.
* **Tiered access** (e.g. NOODL) — Different terms depending on who you are and where you are.
* **Research-only with commercial licensing** — Free for academic and social use; commercial providers pay a licensing fee or enter a benefit-sharing agreement.
* **Fully closed / sovereign** — Data stays within the community or is shared only under strict bilateral agreements.
When deciding, involve the community whose voices are in the dataset. This is their data as much as it is yours.
# 8.3 Gated access, data control, and GDPR
### Gated datasets
Some datasets are configured as “gated” on sharing platforms like Hugging Face. This means users must log in and request access before downloading. When they request access, they provide basic information about themselves and their intended use. Access may be granted automatically or after manual review.
We gate some datasets so we can:
* Track who is using the data
* Ensure responsible use
* Understand the impact of our work
* Stay accountable to the communities who recorded their voices.
### Additional access terms
A license sets the baseline, but you can layer additional terms on top. Users agree to these terms when they request access to a gated dataset, before they can download anything.
These additional terms can cover things the license doesn’t address directly, such as:
* Restrictions on specific applications (e.g. surveillance, military use)
* Requirements to notify the data provider if the dataset is used in a published system
* Obligations to report any data quality issues discovered during use
* Conditions for redistribution.
Additional access terms are not a substitute for a license — they complement it.
| **How do we ensure GDPR compliance on TWB Voice datasets?** |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| All TWB Voice datasets are published with a separate [Dataset Access Terms](https://huggingface.co/datasets/CLEAR-Global/TWB-Voice-dataset-access-terms) document on Hugging Face. When a user requests access to any of our gated datasets, they must read and agree to these terms. This gives us an additional layer of control beyond the CC-BY-NC license: we can specify forbidden uses, require that users contact us if they discover data quality issues, and make clear that we may ask them to delete specific recordings in the future (see below). |
### Why gated access matters for GDPR
Under the EU General Data Protection Regulation (GDPR) and similar data protection frameworks, individuals have the **right to erasure** — the right to request that their personal data be deleted. Voice recordings are personal data.
This means that if a speaker asks for their recordings to be removed, the data must be destroyed not only from the original dataset but from **all copies held by anyone who downloaded it**. If you have no record of who downloaded your dataset, you have no way to contact them and enforce the deletion.
Gated access solves this problem by recording each downloader’s identity and contact information (typically an email address). If a retraction request comes in, you can notify all known recipients and ask them to delete the affected recordings.
| **Consider gated access to keep downloaders contactable** |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Even if you plan to release your dataset under a permissive license, consider using gated access if your dataset contains voice recordings. The ability to contact downloaders is essential for honoring data retraction requests. This is not just good practice — in many jurisdictions, it is a legal requirement. |
# 8.4 Where to publish your dataset
Choosing the right platform matters. A dataset shared through a private link (such as a Google Drive folder) is effectively invisible — no one outside your immediate contacts will find it, and it won’t show up in any catalog or search engine. To make your dataset discoverable and useful, publish it on a platform designed for data sharing.
### Hugging Face
[Hugging Face](https://huggingface.co/) is the most widely used platform for sharing AI datasets and models. It has become the de facto hub for the machine learning community.
You can find TWB Voice datasets, models, and demos on the [CLEAR Global organization page](https://huggingface.co/CLEAR-Global).
**Strengths:**
* Massive user base — your dataset will be visible to the global ML community
* Built-in dataset viewer, version control, and programmatic access via the datasets Python library
* Supports gated access and custom access terms
* Dataset cards (README.md) are rendered directly on the dataset page
**What to be aware of:** Hugging Face is an open platform. Anyone can upload any dataset or model without review or quality checks by the platform. This makes it easy to publish, but it also means there is no curation — the quality and ethical standards of published resources vary widely. For users browsing datasets, this means you need to evaluate what you find carefully.
You can download data through the web interface or use the Hugging Face datasets Python library to access it programmatically:
```
from datasets import load_dataset
ds = load_dataset("CLEAR-Global/your-dataset-name")
```
### Mozilla Data Collective
[Mozilla Data Collective](https://mozilladatacollective.com/) (MDC) is a data-sharing platform incubated by the Mozilla Foundation. It is built around the principle that data contributors should retain control and ownership of their data.
**Strengths:**
* Datasets are reviewed by the platform administrators before being made available — this means a level of curation and quality assurance that Hugging Face does not offer
* Contributors can set their own sharing terms (open source, community governance, or compensation models)
* Allows putting a price on your dataset — contributors can charge for access, making it possible to sustain data collection work financially
* Strong emphasis on multilingual and multicultural datasets
* Aligned with the values of community-driven language technology work.
MDC is a newer platform with a growing catalog. It is particularly relevant for speech and language datasets from underrepresented communities. You can find CLEAR Global's datasets on MDC at [our organization page](https://mozilladatacollective.com/organization/cmgkvykyl00aakz0721yb03cj).
### Other platforms
There are many other platforms for data sharing, some more academic, some more industry-oriented. Below are two that are particularly relevant for speech datasets. We may expand this list in future versions of the playbook.
Speech and language research resources, hosted by Google.
No
No
Focused specifically on speech/language resources for research. Simple hosting — no built-in viewer or metadata system. Well-known in the speech research community.
# 8.5 Working with pre-trained models
CLEAR Global publishes models on Hugging Face with information on their architecture and evaluation results on a test partition of the data we publish.
The models we share are mostly research demonstrations and evaluation tools. They have been tested on specific datasets and may not work well in all real-world settings. These models are not guaranteed for production use. You would need to test them thoroughly before using them in any active system.
When using shared models, consider the following:
* Performance may vary a lot with different accents, recording conditions, or speaking styles.
* Models are trained on limited data, so they may not represent the full range of speakers in a language community.
* For any practical application, they will need regular testing and adjustment.
We suggest that users see these models as starting points for further development, not complete solutions for immediate use in critical humanitarian settings.
# 9. Case studies
#### Chapter 9 overview:
{% hint style="info" %}
This chapter is for project managers, community engagement officers and language leads. It's also for any organization that is planning a **voice data collection project and wants to learn from teams who have already done one**.
In **each case study**, a partner organization **shares**:
* the context and language they worked in
* how they approached data collection
* the challenges they faced and how they dealt with them
* the lessons they learned along the way
Note: The case studies are **practical and based on real experience**. You don't need any technical skills.
{% endhint %}
# 9.1 CIATECH Africa Kanuri voice data collection
Between April and July 2026, [CIATECH Africa](https://ciatech.ng/en) collaborated with CLEAR Global to collect approx. 10 hours of read and spontaneous speech data in Kanuri using TWB Voice, while also generating learnings to help co-design future features of the TWB Voice platform. At the close of the collaboration, CIATECH Africa authored a case study reflecting on their experience. You can read the full case study [here](https://drive.google.com/file/d/1qY3ni43Iboh4zezD6T-9_2JWJE05WWpk/view?usp=drive_link).
Please note that some of the challenges described, as well as references to tool names and functionality, reflect the state of the TWB Voice ecosystem at the time of project delivery and may have since been updated or resolved. We share this case study not as a guide to the specific tools used, but as a window into how different organizations have approached voice data collection in practice, including the decisions, challenges, and lessons that emerge in the process.
# 9.2 Utavu AI Foundation Dholuo voice data collection
Between April and July 2026, the Utavu AI Foundation collaborated with CLEAR Global to collect approx. 20 of spontaneous speech data in Dholuo using TWB Voice, while also generating learnings to help co-design future features of the TWB Voice platform. At the close of the collaboration, CIATECH Africa authored a case study reflecting on their experience. You can read the full case study [here](https://drive.google.com/file/d/1lUSyPqWKXRhM2DdKWMYWnkhBApGJpiUE/view?usp=drive_link).
Please note that some of the challenges described, as well as references to tool names and functionality, reflect the state of the TWB Voice ecosystem at the time of project delivery and may have since been updated or resolved. We share this case study not as a guide to the specific tools used, but as a window into how different organizations have approached voice data collection in practice, including the decisions, challenges, and lessons that emerge in the process.
# Share your feedback
Thank you for reading the TWB Voice Program Playbook.
We hope this playbook has been helpful in supporting your work in planning and managing voice data collection for low-resource languages. Whether you're just getting started or refining your current approach, your efforts are helping to close the data gap and make voice technology more inclusive.
We'd love to hear your thoughts on how the playbook can be improved. \
👉 **Take our short** [**feedback survey**](https://docs.google.com/forms/d/e/1FAIpQLSc9vpLQuoVlr31FCRsAMT5-fJrGnwsN4VhN1Vd2dTNAvoEb7A/viewform?usp=dialog)
Your input helps us ensure the playbook remains practical, relevant, and aligned with your needs.
Thank you for contributing to more inclusive language technology!
![Playbook visula inspi [Recovered]-01.png](https://601326465-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FuBrHBm7MNrq060oOpFNq%2Fuploads%2F9hPkrNCBlaZAvfoWKJvM%2FPlaybook%20visula%20inspi%20%5BRecovered%5D-01.png?alt=media&token=ce281919-b5b9-4d93-ab94-8f20ad0d6f48){kind=link}
![Playbook visula inspi [Recovered]-02.png](https://601326465-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FuBrHBm7MNrq060oOpFNq%2Fuploads%2FcNn6274v82iurYwFGV5f%2FPlaybook%20visula%20inspi%20%5BRecovered%5D-02.png?alt=media&token=0a5810cd-3f9e-440b-b601-4064317d6ad5){kind=link}
![Playbook visula inspi [Recovered]-03.png](https://601326465-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FuBrHBm7MNrq060oOpFNq%2Fuploads%2F4VNU90fMm5HSFoxEzko7%2FPlaybook%20visula%20inspi%20%5BRecovered%5D-03.png?alt=media&token=c1f522ed-b33a-4543-8083-706c18defef6){kind=link}
![Playbook visula inspi [Recovered]-05.png](https://601326465-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FuBrHBm7MNrq060oOpFNq%2Fuploads%2FYw7t7j0SLthGH2IUGxmw%2FPlaybook%20visula%20inspi%20%5BRecovered%5D-05.png?alt=media&token=b2ce3c91-5bb5-4ef6-b7d3-69efffaf0538){kind=link}
![Playbook visula inspi [Recovered]-06.png](https://601326465-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FuBrHBm7MNrq060oOpFNq%2Fuploads%2FyuooG0TxOTsxRi7fK2Nw%2FPlaybook%20visula%20inspi%20%5BRecovered%5D-06.png?alt=media&token=b609204f-a697-4d02-acf6-c28db46a4ab9){kind=link}
![Playbook visula inspi [Recovered]-09.png](https://601326465-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FuBrHBm7MNrq060oOpFNq%2Fuploads%2FMQdM42dwaUR1IWRnR9K5%2FPlaybook%20visula%20inspi%20%5BRecovered%5D-09.png?alt=media&token=c2f6dc18-58cf-4b90-8107-0fffd6ae06f1){kind=link}
\
It marks a quick-reference box that tells you who the chapter is for and what level of expertise you need to read it. Here is the example for this chapter:
{% hint style="info" %}
You don’t need to be a technical expert for this section of the playbook. It’s a good starting point for anyone new to the playbook, whether you want to read a specific section or the whole guide.
{% endhint %}
### Different ways to use this playbook
In each section of this playbook, you will find information, steps you can take, and practical examples from the [TWB Voice](#user-content-fn-3)[^3] platform. These will guide you through the process of collecting voice data. Here are some ways you can use this playbook:
* **Step-by-step learning:** If you are new to [voice data collection](#user-content-fn-4)[^4], start with the early chapters. This will help you to understand the key concepts and stages of a project. You can follow the chapters in order or jump to sections that match your needs.
* **Real-world examples:** Case studies from work completed by both CLEAR Global and partners with TWB Voice provide practical lessons that you can apply to your own projects.
* **Quick reference:** Already collecting data? Use the playbook to look up specific topics when you face problems. For example, how to store and share data.
* **Learn together:** Share ideas, ask questions, and work with partners, experts, and our team.
### Share your feedback!
Send us an [email](mailto:tech@clearglobal.org) or fill out this [feedback form](https://docs.google.com/forms/d/e/1FAIpQLSc9vpLQuoVlr31FCRsAMT5-fJrGnwsN4VhN1Vd2dTNAvoEb7A/viewform?usp=header)! We would love to hear from you to improve this playbook.
**Case study: Defining the scope of CLEAR Global’s pilot project to collect voice data in Hausa, Kanuri, and Shuwa Arabic** |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 
**Key tips: How can I make a practical plan for potential risks?** |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 
**Key tips: How many sentences do I need?** |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 
**Case Study: CLEAR Global’s collection of books in Kanuri** |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 
**Key takeaway** |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 
