That’s when her friend mentioned Celium. “It’s like borrowing a supercomputer from someone down the street,” he’d said. Skeptical but desperate, Amina typed celiumcompute.ai into her browser.

Renting Power: Amina’s Journey

The website felt clean and quiet — no flashy ads, no confusing charts. She clicked “Get Started” and made an account with her email. A payment screen appeared. “What if I run out of money mid-training?” she worried — until she spotted “Auto Top-Up.” She turned it on, linked her debit card, and sighed in relief. She filtered by “cheap + available now” and found one — an NVIDIA RTX 4090 in Lisbon, costing less per hour than her coffee. She clicked Rent.

A box appeared: “Upload your task.” She dragged her Python training script into it. One more click — “Run.”

A progress bar crawled to life.

Training epoch 1/100... 4x faster than local GPU

She closed her laptop, went to sleep, and woke to an email:

“Your task completed. Download results.”

Her model — finished in hours, not weeks.

The Quiet Earner: Mark’s Story

Across the ocean, Mark sat in his dimly lit gaming room in Lisbon. His powerful GPU — the same RTX 4090 Amina used — usually just glowed idle while he worked his day job. “Such a waste,” he’d mutter. Electricity bills piled up.

Then he discovered Celium’s miner program. He downloaded it — a simple installer — and ran it. The software quietly scanned his PC:

• Recognized his GPU
• Tested its speed
• Checked his internet

He set two rules:

1. Only rent when I’m not gaming.
2. Never exceed 80% GPU load.

Then… he forgot about it.

The Invisible Handshake

While Amina’s crop model trained on Mark’s GPU, three things happened in the background — none requiring either to lift a finger:

1. Validators — guardians of the network — connected to Mark’s PC. They verified:

• Was his GPU real? (Yes.)
• Did it deliver the speed promised? (Yes.)
• Did it stay online? (Yes.)
• Was the temperature stable? (Yes.)

2. Bittensor’s blockchain recorded Mark’s contribution, including:

• GPU utilization metrics
• Task completion status
• Resource quality score

3. $TAO tokens dripped into Mark’s digital wallet — automatic payment for the hours Amina used, calculated based on:

• GPU performance tier
• Actual usage time
• Network demand
• Quality of service

The Ripple Effect

A week later:

• Amina presented her AI model to farmers in Kenya.
• Mark used his $TAO earnings to cover his electricity bill — and bought a new game.
• The GPU in Lisbon kept working. A researcher in Seoul rented it next to simulate protein folds.

No one talked about “decentralized subnetworks” or “blockchain protocols.” They didn’t need to. Celium became what tools ought to be:

Useful. Silent. Unnoticed until needed.

How You Start

f you’re like Amina (needing power):

1. Go to celiumcompute.ai
2. Sign up with email or GitHub
3. Pick a GPU based on your needs (RTX 4090 for AI, A4000 for basic tasks)
4. Run your task with automatic optimization

If you’re like Mark (owning a GPU):

1. Download the miner tool from Celium’s site
2. Let it scan your hardware and verify compatibility
3. Set your rules (availability, load limits, minimum payout)
4. Earn while you sleep, with automatic payouts in $TAO

That’s it.
No jargon. No complexity.
Just a tool matching need with resource — 
while the world keeps turning.

Sound unfair? That’s Web2 — the internet we use today, where corporations control platforms and profit from your creativity.

Web3: The Internet Where You Own the Keys

Web3 is like a user-owned Instagram revolution. Instead of your photos sitting on Meta’s servers, they’d live on a decentralized network (think of it as a global web of computers working together, not controlled by any single company). Here’s how it flips the script:

1. You Actually Own Your Stuff

In Web3, your photos would be stored on a blockchain — a shared, unchangeable digital ledger. Think of it like a digital safety deposit box only you can open. You could:

• Move your photos to a different app without losing followers.
• Prove you created them (no more stolen memes!).
• Decide who sees them, forever.

No more fearing a platform’s “terms of service” or arbitrary bans.

2. You Get Paid, Not Just the Platform

Today, Instagram makes money by showing ads next to your content. In Web3, if someone views your photos, you could earn cryptocurrency (like digital coins) directly. Artists, creators, and even casual posters could monetize their work without middlemen taking a cut. Imagine tipping your favorite travel blogger in crypto with one click!

3. You Help Make the Rules

Web3 platforms are governed by decentralized communities, not CEOs. Want a new feature? Vote on it. Hate an update? Propose a change. It’s like a digital democracy where users collectively steer the platform’s future.

How Web3 Fixes the Instagram Nightmare

Let’s revisit our Bali photos:

• No More Landlords: Instead of Meta’s servers, your content lives on a blockchain — maintained by thousands of computers worldwide. No single company can delete it.
• Your Followers Follow You: Your audience isn’t locked to Instagram. Switch apps? Your followers come with you, like email contacts.
• Community-Driven Creativity: Want a “dislike” button or better filters? Rally users and vote — no need to beg Meta’s HQ.

Web3 in Simple Terms: From Renting to Owning

Today’s internet (Web2) is like renting: you decorate the apartment, but the landlord can evict you. Web3 is owning the house. You control the walls, the garden, and even rent out a room for extra cash. It’s a shift from platforms owning us to us owning the platforms.

The Bottom Line
Web3 isn’t just about crypto or NFTs — it’s about rebuilding the internet to put power back in your hands. Will it be perfect? Probably not. But for the first time, we’re asking: What if the internet worked for us, not corporations?

What would you do if you truly owned your digital life? 💡

Ever wondered how to add proper user permissions to your Flask app? For example, making sure admins can do admin things, and regular users stay in their lane?

Let’s build something cool together using Flask and Cerbos!

What We’re Building

We’re creating a simple dashboard where:

- Admins can view, edit, and delete content (the almighty role)
- Editors can view and edit (but not delete!)
- Viewers can only look (no touching!)
- And some users get no access at all

Sound complicated? Don’t worry! We’ll break it down into bite-sized pieces.

How Cerbos Handles Authorization

Here is a diagram that shows how Cerbos processes a user request for authorization by evaluating role policies, applying rules, and ultimately returning a decision to either grant or deny access in our project:

Setting Up Project

First, let’s get our files organized. Here’s what we need:

our-flask-app/
├── app.py # Main Flask app
├── cerbos_service.py # Handles permissions
├── cerbos-policies/ # Where we define who can do what
├── templates/ # HTML files
│ ├── dashboard.html
│ └── index.html
└── requirements.txt # Project dependencies

Step 1: Define the rules

Let’s start with the fun part — deciding who gets to do what! We’ll create a simple policy file named resource_policy.yaml under cerbos-policies folder:

apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: "default"
  resource: "dashboard"
  rules:
    - actions: ["view"]
      effect: EFFECT_ALLOW
      roles: ["admin", "editor", "viewer", "guest"]
    - actions: ["edit"]
      effect: EFFECT_ALLOW
      roles: ["admin", "editor"]
    - actions: ["delete"]
      effect: EFFECT_ALLOW
      roles: ["admin"]
    - actions: ["view"]
      effect: EFFECT_DENY
      roles: ["restricted"]

Think of this like a security guard’s rulebook — it tells us exactly who’s allowed to do what!

Step 2: Creating Permission Checker

Now we need a way to check these permissions. Here’s the part of our cerbos_service.py file:

def is_authorized(user, action, resource):
 """
 Checks if a user can perform an action.
 Think of it like asking "Can this person do this thing?"
 """
 payload = construct_payload(user, action, resource)
 response = call_cerbos_api(payload)
 
 # Returns True if allowed, False if not
 return response.get("resourceInstances", {})
 .get("instance_id", {})
 .get("actions", {})
 .get(action) == "EFFECT_ALLOW"

Step 3: Building Flask App

Here’s where it all comes together in our app.py file:

from flask import Flask, render_template, request
from cerbos_service import is_authorized
app = Flask(__name__)
@app.route('/dashboard')
def dashboard():
 # Get the user's role from the URL (in real life, this would come from login)
 role = request.args.get('role', 'guest')
 user = {"id": "user1", "roles": [role]}
 
 # First, check if they can even see the dashboard
 if not is_authorized(user, "view", "dashboard"):
 return "Sorry, no access for you! 🚫", 403
 
 # Check what else they can do
 can_edit = is_authorized(user, "edit", "dashboard")
 can_delete = is_authorized(user, "delete", "dashboard")
 
 return render_template(
 'dashboard.html',
 role=role,
 can_edit=can_edit,
 can_delete=can_delete
 )

Try It Yourself!

Want to see it in action? Here’s how:

1. Clone the demo:

git clone https://github.com/mhmohona/demo_flask_project

2. Install what you need:

pip install -r requirements.txt

3. Run the app:

python app.py

4. Try these URLs:
 — http://localhost:5000/dashboard?role=admin (full access!)

— http://localhost:5000/dashboard?role=editor (can edit but not delete)

— http://localhost:5000/dashboard?role=viewer (look but don’t touch)

— http://localhost:5000/dashboard?role=restricted (no access)

Cool Things About This Approach

1. Super Clean Code: Your Flask routes stay nice and tidy
2. Easy to Change: Want to add a new role? Just update the policy file!
3. Security First: All permission checks in one place = fewer mistakes

What’s Next?

Now that you’ve got the basics down, you could:
- Add more roles (maybe a “moderator”?)
- Create different resources (like “posts” or “comments”)
- Add user authentication (who’s actually logged in?)

Need Help?

- Check out the full code in the demo repo
- Read more in the Cerbos docs
- Try different roles, policies and see what happens!

Happy coding! 🎉

Development Process

The motivation behind creating the Scribe-Data CLI was to provide users with an efficient way to interact with language data from various sources, including Wikidata. The development process involved several key steps:

1. Designing the CLI Structure: With the help of my GSoC mentors, I started by outlining the commands and options that the CLI would support.
2. Implementing Command Handlers: Each command was implemented in separate modules for better organization.
3. Testing and Iteration: I continuously tested the CLI to ensure it met user needs and fixed any bugs that arose. I also added unittest to ensure CLI’s quality.

Key Features

Global Options

The CLI supports several global options that enhance usability:

# python:src/scribe_data/cli/main.py
parser.add_argument(
 "-h", " - help", action="help", help="Show this help message and exit."
)
parser.add_argument(
 "-v", " - version", action="version", version="Scribe-Data CLI v1.0"
)
parser.add_argument(
 "-u", " - upgrade", action="store_true", help="Upgrade the Scribe-Data CLI."
)

Commands Overview

The Scribe-Data CLI supports the following commands:

1. list: Lists available languages and data types.
2. get: Retrieves data from Wikidata.
3. total: Checks the total available data.
4. convert: Converts data to different file formats.

List Command

The `list` command allows users to view available languages and data types supported by Scribe-Data.

# src/scribe_data/cli/list.py
def list_languages():
 # Fetch and display available languages
 languages = fetch_languages_from_source()
 for lang in languages:
 print(f"{lang['name']} - {lang['iso']} - {lang['qid']}")

This function fetches the list of languages from a data source and prints each language’s name, ISO code, and QID. It demonstrates how the CLI interacts with the underlying data to provide users with meaningful information.

Get Command

The `get` command retrieves data based on user specifications.

# python:src/scribe_data/cli/get.py
def get_data(language, data_type):
 # Logic to fetch data from Wikidata
 data = fetch_data_from_wikidata(language, data_type)
 if data:
 save_data(data)
 else:
 print(f"No data found for {language} and {data_type}.")

This function fetches data for a specified language and data type from Wikidata. If data is found, it saves it; otherwise, it notifies the user.

Total Command

The `total` command checks on Wikidata the total number of available lexemes.

# python:src/scribe_data/cli/total.py
def get_total_lexemes(language, data_type):
 # Logic to calculate total lexemes
 total = calculate_total_lexemes(language, data_type)
 print(f"Total number of lexemes for {language} and {data_type}: {total}")

This function calculates and displays the total number of lexemes for a specified language and data type, providing users with a quick overview of available data.

Convert Command

The `convert` command allows users to convert data files into different formats.

# python:src/scribe_data/cli/convert.py
def convert_file(file_path, output_format):
 # Logic to convert file to the specified format
 if output_format == 'json':
 convert_to_json(file_path)
 elif output_format == 'csv':
 convert_to_csv(file_path)

This function handles the conversion of data files to various formats, allowing users to choose their preferred output type.

Interactive Mode

The interactive mode enhances user experience by allowing users to select options through a guided interface. This mode is particularly useful for those who may not be familiar with the command syntax.

# python:src/scribe_data/cli/interactive.py
def run_interactive_mode():
 """
 Run the interactive mode for Scribe-Data CLI.
 """
 selected_languages = select_languages()
 selected_data_types = select_data_types()
 output_options = get_output_options()
# Process the selections

In this function, users are guided through selecting languages, data types, and output options. The interactive mode simplifies the process, making it accessible for users who prefer a more visual approach.

Creating the Scribe-Data CLI was a rewarding experience that taught me valuable lessons about user needs and command-line design.

Feel free to check out the Scribe-Data GitHub repository for the complete code and further details.

We’re almost at the finish line of GSoC, and I can’t believe how fast the time has flown by!

The Latest Progresses

Docker Dilemmas
This week was all about Docker — well, trying to make friends with Docker (even though my device didnt support me)! I was deep into learning the ins and outs of containerizing our CLI, but I’ll be honest, it felt like wrestling an octopus at times. I made some progress understanding deployment strategies, but there’s still some way to go before I master it.

Command Central
Docker wasn’t quite playing nice, so I decided to focus on some fun stuff instead! I rolled up my sleeves and got to work on some new commands for the CLI. I added the `version` command to help users check which version of the tool they’re using and then `upgrade` command.

Smooth Sailing… Almost!
I’ve been refining and tweaking to make sure everything runs smoothly. Added some unittests to make sure our CLI works as expected. And yes, I’m still wrestling with Docker a bit (a bit??!!!), but I’m determined to figure it out. You know what they say — slow and steady wins the race, right (finger crossed)? My mentor, Will really helped me to figure it out where and why I am facing the problem, and it was super helpful.

The Ups, the Downs, and Everything in Between

These last few weeks have been a mixed bag of emotions — some days I feel like I’m on top of the world, and other days, it feels like I’m stuck in a coding maze with no exit in sight. 😂 The Docker stuff has been tricky, and there were days I didn’t make any headway at all. For some reason it occupies too much space which results crashing, slowing down, freezing my device.

Feeling All the Feels

I have to give a huge shoutout to my mentors, Will, Andrew, and Henrik — you guys are the real MVPs! 🙌 Thanks for the support. Your guidance has been everything! ❤️

I’m so excited to see where this project goes and to finally see our Scribe-Data CLI making waves in the Wikidata world. 🚀

Until then, I’ll be here, coding away with my fingers crossed and my dance moves ready for every little win (with my sweet little toddler)! 💃✌️

Let me introduce you with Vitess — the super-smart assistant for your databases, making them work better together and grow more easily.

What I’ve Been Working On

So, remember how I said we were turning Scribe-Data into a command-line tool? Well, we’re making it happen! Here’s what I’ve been up to:

1. Feature Implementation: I’ve submitted several pull requests that add crucial functionality to our CLI:

• Added timestamp functionality to our data outputs (PR #162)
• Implemented new features for data retrieval and storage (PRs #167, #168)
• Worked on improving the overall structure and usability of the CLI

1. Documentation: I’ve started developing comprehensive documentation for the CLI (PR #170). This will be crucial for future users and contributors to understand and utilize our tool effectively.
2. Deployment Preparations: I’ve been studying Docker deployment strategies to ensure our CLI can be easily distributed and run in various environments.

The Ups and Downs

Not gonna lie, some days I feel like a coding wizard, and other days… well, let’s just say Stack Overflow, chatgpt become my best friend. But hey, that’s how we learn, right?

The best part? Every time I solve a problem, I do a little victory dance. My two years olf toddler judges me, but whatever. 🐱💃

Also currently there is a critical situation going on for my country, which caused internet blackout for straight 7 days, and I had no choice but to stop working on my project.

What My Mentors Think

Okay, so my mentors gave me some feedback, and I’m not crying, you’re crying! They said:

“Your input on the structure of the CLI has been of great importance, and your focus on the end user has really helped guide us towards a better product. We’re more than confident that the latter stages of the project will go well, and can’t wait for you to start documenting and sharing information on what Scribe-Data can do!”

I’m going to print this out and stick it on my wall for motivation. Maybe get it framed? Too much? 😂

What’s Next?

So, what’s the plan for the rest of GSoC? Glad you asked!

1. Finish writing that guide (future users will thank me)
2. Make sure anyone can easily install our tool
3. Get our tool running smoothly in Docker
4. Keep adding cool features to make the tool even more awesome

I’m super excited about where this project is going. We’re creating something that’s going to make working with Wikidata language packs so much easier. How cool is that?

Stay tuned for more updates! Catch you on the flip side! ✌️

Week 1: Getting Started

I kicked things off by meeting my mentors to plan out the project. We decided how to organize everything, which was super helpful. I also wrote a SPARQL query to find Bangla adjectives and prepositions in Wikidata. At first, I was worried when I didn’t get the results I expected, but Andrew (my mentor) helped me figure it out. I learned a lot about how to use Wikidata’s search system!

Week 2: Building the Basics

This week, I started creating the actual command-line tool. I made it show a list of available languages and word types for each language.

It was challenging, but I learned many things about how command-line tools are structured. I also planned to add more features next week, like searching for specific words and changing how the results are saved.

Week 3: Making Progress

I spent this week improving the tool. I finalized how all the files should be organized in our GitHub repository. With the help of mentor, I also made the tool better at searching for words based on language and word type.

I’m starting to understand more about how Scribe-Data works as a whole.

Week 4: Putting It All Together

The changes I’ve been working on for weeks finally got approved and added to the main project. That felt amazing! I also added some new features:

• Users can now choose where to save their results.
• The CLI tool can create different types of files (.json, .csv, and .tsv) to store the data.

A Big Thank You to My Amazing Mentors!

I couldn’t talk about my GSoC experience without mentioning the incredible mentors guiding me every step of the way. They’ve been super helpful, supportive, and kind throughout this journey. I want to give a special shoutout to:

• Will Yoshida
• Andrew McAllister
• Henrik Thomasson

These awesome folks have been there for me whenever I’ve had questions or felt stuck. Their expertise and encouragement have made this experience so much more rewarding.

Whether it’s helping me understand complex concepts, reviewing my code, or just offering words of encouragement, my mentors have been instrumental in my progress. I’m incredibly grateful for their patience and dedication. They’re not just mentors; they’re becoming role models for my future in open-source development.

To Will, Andrew, and Henrik: Thank you for your time, knowledge, and support. You’re making this GSoC experience unforgettable. ❤️

What’s Next?

I’m not done yet! There are so many things I need to and want to do for this project. My goals for the coming week are to:

1. Finish adding all the planned features to the tool.

2. Fix any bugs I find.

3. Start writing documentation on how to use the tool

I’m having a blast working on this project. It’s challenging, but I’m learning so much. I can’t wait to see what the rest of the summer brings!

Sometime building applications from source code can be a challenging task. You need to install all the different software, set up the right environments, handle multiple dependencies and follow specific steps to create a working program… and then after doing all the hassle you can expect the application to run.

Wouldn’t it be wonderful if someone could do all of the job for you? That’s where buildpacks come in!

What are Buildpacks?

Buildpacks is the tool that helps you to create ready-to-run applications without all the ground work. It is like a personal assistant that take your application code and transform it into a complete package, including all the necessary software and settings.

For example, if you want to bake a cake, you need to gather ingredients, prepare the batter, and bake it in the oven. With buildpacks, all you need to do is providing the recipe (your code), and they’ll take care of everything else, from gathering the ingredients to baking the cake!

Why Use Buildpacks?

1. Easy Peasy: Buildpacks simplify the process of creating applications. You don’t need to worry about installing dependencies, setting up environments or anything. Just provide your code, and the buildpack will take care of the rest.

2. Consistency is Key: Buildpacks ensure that your application is built the same way every time, no matter where you’re building it. This means you won’t have to deal with “it works on my machine” issues.

3. Language Lovers: Buildpacks supports a wide range of programming languages and frameworks, so you can use your favorite languages and frameworks to build your applications.

4. Cloud-Ready: Buildpacks are designed to work seamlessly with containers, which are like portable boxes for applications. This makes it easy to run your applications in the cloud or on different machines.

Getting Started with Buildpacks

To start using buildpacks, you’ll need to install a tool called the `pack` CLI, which helps you build your applications using buildpacks.

Here’s how you can install it:

- macOS: Run `brew install buildpacks/tap/pack` in your terminal.
- Linux: Follow the instructions in the pack repository for your specific Linux distribution.
- Windows: Download the pack executable and add it to your system’s PATH.

Once you have the `pack` CLI installed, you can build your application by running the following command in your project folder:

pack build my-app - path .

This command tells the `pack` CLI to look at your application code in the current folder (`.`) and use a buildpack to create a container image called `my-app`.

Exploring Buildpacks

The `pack` CLI comes with some default buildpacks, but you can also use other buildpacks created by the community. The [Cloud Native Buildpacks organization](https://github.com/buildpacks) on GitHub has official buildpacks for popular languages like Java, Node.js, Go, and more.

To use a specific buildpack, you can pass the ` — buildpack` flag to the `pack build` command:

pack build my-app - path . - buildpack=gcr.io/paketo-buildpacks/nodejs

This command tells the `pack` CLI to use the official Node.js buildpack from Paketo Buildpacks to build your application.

Real-Life Example

Let’s say you have a simple Node.js application with a few files: `index.js`, `package.json`, and some other files. Without buildpacks, you would need to install Node.js, install all the dependencies listed in `package.json`, and then run your `index.js` file.

With buildpacks, you can skip all those steps! Just run the `pack build` command, and the buildpack will:

1. Install Node.js for you
   2. Install all the dependencies from `package.json`
   3. Compile your code
   4. Create a container image with your application ready to run

We can see below diagram to understand the steps involved in using buildpacks to transform your Node.js application into a container image, ready to run:

That’s it! You can then run your application using the container image without worrying about setting up the environment or installing dependencies.

Conclusion

Buildpacks are amazing tools that make building applications much easier and more consistent. They handle all the tedious setup and installation tasks, so you can focus on writing great code. With the `pack` CLI and the wide variety of available buildpacks, getting started is simple, even for beginners. Give buildpacks a try and experience the convenience and power they bring to your development workflow!

If you want to learn more about buildpacks, check out the official Cloud Native Buildpacks documentation and the Cloud Native Buildpacks community resources.

Welcome to the world of Scribe-Data, a fascinating project that’s all about making language data more accessible and useful for everyone. This blog post will take you through the basics of Scribe-Data, how it works, and how you can contribute to this exciting project.

What is Scribe-Data?

Scribe-Data is an open-source project that provides scripts and tools for extracting and formatting linguistic data from Wikidata and Wikipedia. This data powers various applications developed by Scribe, which aims to create tools and applications that help people learn and use different languages. The data collected by Scribe-Data comes from sources like Wikidata and Wikipedia, and the data is then used to power commands in Scribe applications to allow users to conjugate verbs and translate from one language to another.

At its core, Scribe-Data contains Python scripts that interact with the Wikidata and Wikipedia APIs to retrieve and process information related to languages and writing systems. This data is then used to build language interfaces and input methods for Scribe’s cross-platform applications.

How Does Scribe-Data Work?

Scribe-Data uses SPARQL to query data from Wikidata. SPARQL is a bit like asking a librarian for books on a specific topic. In this case, it’s asking for information about languages, words, and how they’re used. This data is then organized and made available for Scribe applications to use.

The main data update process is initiated by running a script named `update_data.py`. This script triggers SPARQL queries to query language data from Wikidata.

To run the `update_data.py` script, you use a command-line interface (CLI) command from the Scribe Data folder:
```
python3 src/scribe_data/extract_transform/wikidata/update_data.py
```
This command is executed to start the data update process, which is a fundamental part of how Scribe-Data works to keep language tools current and effective.

There are other scripts for retrieving popular words from Wikidata and the words that typically follow them to create an effective autosuggestion feature. This feature is crucial for enhancing the user experience by providing relevant suggestions as users type. Additionally, emojis are sourced from Unicode, ensuring a rich and engaging user interface.

Accessing and Using Scribe-Data

The Scribe-Data project is hosted on GitHub at the following repository: https://github.com/scribe-org/Scribe-Data. Developers and users can access the project’s source code, scripts, and documentation from this central location.

The repository’s directory structure is organized as follows:

• extract_transform/: Contains scripts and tools for extracting and transforming language data from sources like Wikidata and Wikipedia, preparing it for use in Scribe applications.
• load/: Includes scripts and utilities for loading and processing language data into a usable format for Scribe applications.
• resources/: contains commands and metadata about supported languages, including their names, codes, scripts, writing directions and plural rules, which are used to configure language tools in Scribe applications.

The project’s README file offers detailed guidance on setting up the development environment, running the data extraction scripts, and understanding the overall project structure. This documentation serves as a valuable resource for those who want to get started with Scribe-Data.

Benefits of Using Scribe-Data

Scribe-Data offers so many benefits, making it an invaluable resource for developers and users :

- Rich Language Data: By leveraging the vast amount of language data from Wikidata and Wikipedia, Scribe-Data enables the creation of language applications that support a wide range of languages and writing systems.
- Cross-Platform Tools: The data and scripts provided by Scribe-Data facilitate the development of language tools that are not only functional and feature-rich but also compatible across different platforms, including iOS, Android, and Desktop.
- Accessibility and Communication: Scribe-Data plays a crucial role in promoting accessibility and breaking down communication barriers. It provides effective language input and interface solutions, making it easier for people from different linguistic backgrounds to communicate and interact.

Contributing to Scribe-Data

Scribe-Data welcomes contributions from the community. Whether you’re reporting bugs, working on new features, or adding language data via Wikidata, there’s a place for you in the Scribe-Data project. The repository’s contributing and README section provides detailed guidelines and resources for those interested in contributing. For first-time contributors, issues marked with `good first issue` are designed to help you get started.

Whether you’re a language enthusiast, a developer interested in open-source projects, or someone seeking to break down communication barriers, Scribe-Data is a project worth exploring and supporting. By getting involved, you can play a vital role in shaping the future of language-focused applications and making a positive impact on the way people learn, communicate, and connect across the world.