跳到正文
DEV Community· Charles Zhang·· 3 小時前AI 評分39

以 Claude 和 Divooka App Platform 建構 Multilingualism

Building Multilingualism with Claude and Divooka App Platform

AI 導讀

作者透過 Divooka App Platform 的 MCP connector,使用 Claude 建構多語詞典 Multilingualism。數據集涵蓋 108 種語言的 9,852 個英文詞語及短語,包含逾一百萬筆翻譯,約一半取自 Wiktionary,其餘缺漏以機器翻譯補足。

正文

There is an interesting theory in linguistics, namely the arbitrariness of the linguistic sign: there is no inherent or necessary connection between a word's sound (the signifier) and its meaning (the signified).

Background

The arbitrariness of the linguistic sign - a fundamental principle of linguistics associated with Swiss linguist Ferdinand de Saussure - dictates that there is no inherent or necessary connection between a word's sound (the signifier) and its meaning (the signified).

For example, the same animal is called:

  • English: dog
  • French: chien
  • German: Hund
  • Japanese: inu (犬)
  • Mandarin: gǒu (狗)

These different sounds refer to essentially the same concept. Nothing about the animal inherently requires any particular pronunciation. Saussure formalized this principle in his Course in General Linguistics (1916).

However, arbitrariness doesn't mean complete randomness. There are important qualifications, including onomatopoeia (words imitating sounds), sound symbolism (certain sounds being associated with particular qualities), and historical relationships between languages.

The deeper implication is that meaning is established through social convention rather than through any intrinsic relationship between sound and concept.

Motivation

I'm not a language expert. I just enjoy exploring languages, particularly when designing my own fictional languages. Sometimes I want to know how a word or phrase is expressed across different languages, either out of curiosity or simply for inspiration.

For years, In Different Languages has been a great resource for this. Enter an English word, and you get translations in over 100 languages. Simple and useful.

Unfortunately, the website frequently becomes unavailable or unreasonably slow. Sometimes a simple word lookup takes far longer than it should.

To be clear, I never had a problem with its advertisements. Hosting a website costs money, and I have no objection to reasonable monetization. My frustration was purely about reliability and responsiveness.

Eventually, I thought: why not build my own?

There was another motivation. I've been developing Divooka App Platform, and wanted a practical project to test its capabilities. Rather than making another trivial demo, I figured a multilingual dictionary would be a useful real-world test.

That's how Multilingualism came about.

Building with Claude and Divooka

The entire application was built with Claude through Divooka App Platform's MCP connector.

Instead of manually writing the website and processing scripts, I worked with Claude to define the requirements, develop the translation pipeline, implement the interface, and iterate on the results.

For me, this was as much an experiment in AI-assisted development as it was a dictionary project. I wanted to see how far we could take a complete, usable application through the platform's MCP integration, rather than just generating isolated code snippets.

The initial concept was straightforward: gather translations from available open sources, fill missing entries where possible, and publish the results through a fast, lightweight website.

Of course, collecting translations is one thing. Making them reasonably consistent across 108 languages is another.

Since I'm not a linguist, I didn't want to pretend I could personally verify every translation. Instead, we designed the process around existing dictionary data, explicit source attribution, automated checks, and community corrections.

Building the Translation Dataset

We started with the English Wiktionary, using structured extracts provided by kaikki.org through Wiktextract.

Rather than importing the entire dictionary, Claude helped build a Python pipeline that processes the data in several stages:

  1. Extract: Stream the Wiktionary JSONL dump, keeping English entries with translation tables, definitions, parts of speech, and relevant metadata.
  2. Select: Use wordfreq to prioritize common English words and phrases, considering translation coverage and normalizing language variants.
  3. Fill: Identify missing word-language pairs and generate translation jobs for Claude, including the intended meaning and part of speech.
  4. Validate and merge: Compare machine-generated results against hidden Wiktionary control samples, flag uncertain translations, and prioritize Wiktionary when both sources are available.
  5. Publish: Generate compact JSON files organized by word and language, along with metadata and source information.

We also use Princeton WordNet to organize words into categories.

The resulting dataset contains 9,852 English words and phrases across 108 languages, representing over a million word-language translation entries. Roughly half come from Wiktionary, with the remaining gaps filled by machine translation.

One interesting challenge is that translation isn't always one-to-one. A word like "light" can refer to illumination, weight, or colour. Translating the wrong meaning produces perfectly valid words that are completely wrong in context.

The pipeline therefore considers definitions and senses rather than translating isolated English strings.

There are also complications involving writing systems, transliteration, dialects, archaic forms, and regional conventions. For example, Simplified versus Traditional Chinese, or Serbian versus Croatian spelling conventions.

Quite a bit of processing logic goes into these details.

A Website Without a Backend

For the website itself, we deliberately kept the architecture simple.

The frontend uses plain HTML, CSS, and JavaScript. No frontend framework, no build step, and no application server.

All translation data is stored as JSON in the GitHub repository and served through the jsDelivr CDN. The application fetches only the necessary files, caches requests in memory, and falls back to GitHub-hosted data if the primary source fails.

There is no reason to query a translation model every time someone looks up a word. The expensive processing is done ahead of time.

This design also gives us something useful almost for free: a public JSON API.

For example, the following URL retrieves translations for "thank you":

https://cdn.jsdelivr.net/gh/MethodoxTech/Multilingualism@main/data/words/thank_you.json

Developers can also retrieve complete language datasets, such as data/langs/ja.json, or the full word index. For reproducible applications, CDN URLs can be pinned to a specific Git commit instead of main.

There's no API key, authentication, or dedicated backend to maintain. The data is also accessible directly from JavaScript applications through CORS-enabled responses.

More details are available on the API page.

Accuracy and Open Contributions

Naturally, machine translation isn't perfect, especially across so many languages.

We generate translations with specific meanings and language conventions, and use control samples to estimate agreement with existing Wiktionary translations. However, automated checks are not a substitute for native-speaker review.

That's why we explicitly identify machine-generated translations, including those marked as uncertain, rather than presenting everything as equally authoritative.

We also preserve the translation sources and publish machine-generated entries as reviewable TSV files.

If you spot an incorrect or awkward translation, you're welcome to open a GitHub issue. The website provides a correction link that pre-fills the relevant context.

Corrections to Wiktionary-derived translations are best contributed upstream, so other projects can benefit from them as well.

The application and pipeline code are MIT-licensed, while the translation data is published under CC BY-SA 4.0.

Final Thoughts

Multilingualism started from two rather different motivations: my frustration with an unreliable but otherwise useful website, and my curiosity about what Claude could build through Divooka App Platform.

The result is a small but practical application that I can actually use when exploring languages or inventing my own.

It's also a useful test of the development platform itself. We went beyond a simple UI demo and built a complete data-processing workflow, a static frontend, and a publicly accessible API through an AI-assisted development process.

I don't expect the dictionary to be perfect. Language is complicated, and even native speakers sometimes disagree on the most appropriate translation.

But the project is open. Anyone can inspect the data, report mistakes, suggest improvements, or use the JSON in their own applications.

And perhaps that's the part I appreciate most: something that began as a personal frustration has become a useful application and a real-world development experiment.

Try it: https://multilingualism.divooka.app/

Source code: https://github.com/MethodoxTech/Multilingualism

Built with: https://divooka.app/

來源:DEV Community · dev.to