Write to a person, or go straight to the page that already does it.

The fastest route is the form on the entry itself: on a word entry it is called Propose an edit. It carries the previous wording with it, so the correction is checked against what a source printed rather than copied over it. Write to the address when the thing that is wrong is not an entry — a page, a cross-reference, a sentence on this site.

What makes a correction publishable, whichever route it takes:

• Which entry. The headword and its language, or the entry’s own address. A word entry lives at /word/{language}/{slug}, so the address in the browser bar is the whole of it.
• Which part is wrong. The meaning, the spelling, the tone marks, the part of speech, the variety a variant is filed under, the example sentence, or the source.
• What it should say. Not only that something is wrong — the wording you would put in its place.
• Who says so. The variety you speak, the town you are from, a printed source with its page, or the person who told you. An entry keeps its source with it, which is why a correction that carries one is a correction an editor can publish.

If the problem is the spelling and you cannot type ị ọ ụ ṅfrom your keyboard, write it plainly anyway: the search folds the marks, so ọ́ria is still found by oria and ṅ by n.

An API problem is usually solvable from the report alone if it carries four things. The reference has the parameters, the error codes and the limits, and /support answers the questions the reference raises.

• The request. The method and the full path, with the query string: GET /api/v1/words?q=mmiri&limit=5.
• What came back. The HTTP status and the error code. Every error has one shape — { error: { code, message, details? } } — so the code alone usually names the fault.
• Whether a key was sent, and in which header: X-API-Key or Authorization: Bearer. Send the request with the key replaced by a placeholder, never the key itself.
• For a limit question, the X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Used headers on the response, and the UTC day you hit it: the counters reset at 00:00 UTC.

One thing worth knowing before writing: a key is shown once, when it is created, and the database keeps only its hash and a prefix. A lost key cannot be recovered by anyone, so a new one has to be created at /developers.

There is no public bug tracker and no issue queue to file into, so a bug report is an email or it is nothing. Four things make one fixable:

• The address of the page, exactly as it appears in the browser.
• What you expected and what happened instead. A report that says only that something does not work is true, and hard to act on.
• Whether you were signed in. An entry page and a form look different to a reader who is not, and the difference is often the bug.
• Whether the browser is part of it. The device and the browser, if it breaks on one and not another — and whether scripting is on, since these pages are built to work with it switched off. A page that only breaks without JavaScript is a real fault, and worth naming.

A screenshot helps when the fault is visual. A recording that will not play is worth naming by entry: a control that says “recording unavailable” is a different thing from one that has not started.

Write from the address on the account. That is how a request about an account can be checked, and for a deletion it is the only way it can be acted on.

• Say what you want in the first line. Delete the account, reset the password, revoke a key, change the display name.
• For a deletion, say whether the recordings you made should come down as well. A recording is a person’s voice and is taken down on request; a published word or meaning may stay, because removing it would take part of the language record rather than part of the account. /privacy sets that out in full.
• Nothing secret. No password, which is stored only as a salted hash. No full API key — and if one has already been sent, revoke it.

A forgotten password does not need the address at all: /forgot sends a one-use link that stops working after sixty minutes, and /support answers the rest.

No refund or receipt policy is published on this site, so no answer can be promised from this page — but the question can be asked, and this is what makes it answerable:

• The date and the amount, and the currency it was given in — naira or dollars.
• One-time or monthly. A monthly gift is a subscription held at the payment provider and it can be cancelled; a one-time gift has no subscription to cancel.
• The provider’s reference, if you have one. Card payments are settled on Paystack’s page and crypto goes through NOWPayments; the reference is what a payment is found by.
• What you would like: a receipt, a correction, or a cancellation.

Never send card details. The payment is finished on the provider’s own secure page, and this site never sees a card number.

Word lists, school vocabularies, family histories of names, printed dictionaries and sets of recordings are the most valuable thing anyone can send, and they do not have to arrive one entry at a time. Say:

• What it is — words, names, proverbs or pronunciations.
• The language and the variety. A language with nothing in the record is the one a first word changes most.
• The form it is in — a spreadsheet, a text file, a scan, a recording, or paper — and roughly how much of it there is.
• Where it came from, if it came from somewhere: a book, a paper, a person. An entry keeps its source.
• How it may be credited, if a credit matters to you. Every recording is credited to the speaker who made it; a word entry carries its sources rather than a byline. If a public credit under your own name matters, a recording is the contribution that carries it.

If it is one word, the form is faster than the mail: /contribute/word takes a headword, its language, a meaning and a part of speech, and four fields is a complete entry.

/privacy sets out what is collected, how it is used and how to have it deleted. /terms sets out what you may do with the dictionary and its data, what is expected of a contribution, and what is not promised. Neither is restated here, so the two cannot disagree.

• For your own data — to see it, correct it, delete it, or ask for a portable copy — write from the address on the account and say which of the four you want. Section 8 of /privacy is the list.
• To delete an account, that same address and the word delete is the whole of the request.
• For a copyright or attribution question, say what has been published and where. /docs/licensing is the page that says what to carry.

The answer to the first half is at /docs#fair-use: use the dictionary freely, for anything, commercially included, and say it came from Ozituma. What makes a reuse question answerable is:

• What you are building, and whether it is commercial. The permission is the same either way; what changes is what the answer suggests next.
• How much you need — a few entries a day, or the whole record. Bulk downloads are allowed on the Team and Institution plans, and anything above the free plan is answered by writing rather than by a form, which is the one API question that needs this address.
• The attribution line you plan to carry, if you want it checked. The document’s own licence line is “Free to use; credit Ozituma”; a name entry prints a fuller citation at its foot.
• The format, if you need an export.