dot.case

What dot.case is

dot.case writes identifiers in lowercase with periods (dots) separating words. The convention isn't widely used for code identifiers — most programming languages reserve the dot for member access — but it appears in specific contexts where hierarchy or namespace matters: configuration keys, internationalization (i18n) translation files, package names in some ecosystems, and structured logging field names.

The convention is sometimes called dotted notation or dot notation, though "dot notation" more commonly refers to the syntax for accessing object properties (user.profile.name) — which uses the same separator but isn't a naming convention per se.

Where dot.case appears

• i18n translation keys: nearly every internationalization library uses dot-separated keys to represent hierarchical translation namespaces. auth.login.button, errors.network.timeout, home.hero.headline. Tools like i18next, formatjs, and the Vue i18n plugin all use this convention.
• Configuration namespaces: tools like Spring Boot, Log4j, and various config-file formats use dotted keys to represent nesting. spring.datasource.url, logging.level.root. This works because the dot acts as a path separator, mapping flat keys onto a tree structure.
• Java package names: reversed-domain notation. com.example.app.services. The dots represent package nesting and map directly to directory structure.
• Python module imports: import os.path, from urllib.request import urlopen. The dots separate package hierarchy.
• Structured logging: http.request.method, user.session.id. Log fields use dotted paths to represent nested context.
• MongoDB field paths: nested fields are addressed with dot notation. address.city, profile.contact.email.
• JavaScript object paths in libraries like lodash: _.get(obj, 'user.profile.name').

The hierarchical signal

What makes dot.case useful is that the separator carries meaning beyond word separation. In snake_case or kebab-case, the separator is purely visual — it makes the identifier readable but doesn't indicate structure. In dot.case, the separator usually represents either nesting (parent.child relationships) or namespacing (organization.product.module).

This is why dot.case works for translation keys: auth.login.button isn't three words describing the same thing; it's a path into a translation tree. The translation file might literally be structured as { auth: { login: { button: "Sign in" } } }, and the dotted key navigates that structure.

Conversion considerations

Converting arbitrary text to dot.case is unusual because the convention typically reflects pre-existing hierarchy that the converter can't infer. But there are valid cases:

• Converting from another flat convention: user_profile_name (snake_case) to user.profile.name (dot.case). The transformation is mechanical: replace underscores or hyphens with dots and lowercase.
• Generating translation keys from UI text: "Sign In Button" becomes sign.in.button. The conversion produces a key, but the resulting hierarchy is arbitrary — there's no semantic nesting, just word boundaries.
• Building config keys from descriptive labels: "Max Database Connection Pool Size" becomes max.database.connection.pool.size.

Limitations

dot.case can't be used as a programming language identifier in most languages because the dot is reserved for member access. You can't write const user.name = "Alice" in JavaScript — the parser will try to interpret it as assignment to a property of user. This limits dot.case to string contexts (keys, paths, configuration values).

The convention also collides with file extensions and version numbers. A key like config.v1.2.html mixes dot.case separators with semantic dots (the version "1.2" and the extension ".html"). Most config systems handle this with explicit escaping or by reserving certain dot positions for semantic uses.

dot.case versus path/case

The conventions are closely related. path/case uses forward slashes; dot.case uses periods. Both represent hierarchy. The choice between them is usually contextual: paths are used where filesystems or URLs are involved; dots are used in configuration, packages, and structured data.

Some tools accept either — for instance, the JSON Pointer spec uses slashes (/user/profile/name) while jq uses dots (.user.profile.name). The information represented is the same; only the syntax differs.