How to read our guides
Editorial policy
Our standard is to separate documented facts from interpretation, and useful examples from evidence.
Effective .
Sources should fit the claim
For character names and encoding history, use Unicode documentation. For software instructions and app-specific meanings, use the platform's own support material. For slang and memes, distinguish documented uses from later explanations of how a term spread.
A linked source should support the nearby claim. An early archived example does not, by itself, establish who invented a phrase.
Examples illustrate usage
Example messages and hypothetical conversations explain tone. Unless an example is explicitly attributed, read it as an illustration written for the entry, not a quotation from a real person or evidence of how common that usage is.
Be clear about uncertainty
Internet language varies across communities and changes over time. Origins may be disputed, and a character can have several interpretations. Guides should explain those limits rather than present one meaning as universal.
AI assistance is not a source
AI tools assist with drafting and site development. Their output is not evidence for a factual claim. Dates, shortcuts and platform rules should be checked against identifiable sources. A documentation check should not be described as hands-on testing; device testing should state what was actually tested.
Dates describe real work
A “documentation checked” date records when the cited instructions were reviewed. It does not promise that an app has stayed unchanged since then. Modification dates should reflect a meaningful change to that page, not simply a new site release.
Checking a possible error
Compare the specific claim with the linked source. For software instructions, note the device, operating system and app version: different versions can have different menus. A useful correction identifies the page, the wording in question and a source or reproducible example.