If you look over my shoulder as I process stuff into my Zettelkasten, dear programmer friend, you may read along and then scream in terror:

How can you pick such a title? It’s clear as day that this won’t be good for long! Just think of … and … to realize that the title needs to be improved!

Programmers worth their salt are notorious to focus on edge cases, much to the dismay of non-programmers around them, who fail to see the relevance to be that accurate and all-encompassing when it comes to everyday things. Sorry: That’s part of our job, that’s a reflex you won’t get us to unlearn.¹

This reflex can get in the way of making a note-taking system like a Zettelkasten work, though.

If you create notes for domains you feel somewhat competent in, you will surely find ways to second-guess what you’re writing. Including the title. How do you make a title future-proof, eternal, rigid and unmoving? How do you prevent future errors and mistakes? Etc. – We’ve been bitten once, twice, a hundred times before, so we can anticipate future problems and prevent them now, and that surely would be worth it!

The Itch for Premature Abstraction

With a couple of years of coding under your belt, you will have gone through this no doubt.

When we’re actually coding, we eventually learn that yes, this nagging feeling is valuable feedback, but no, we don’t need to act it out immediately, because we will also have been bitten by making code too complex now, making it harder to change later, when everyone learned more about the actual feature that needs to be implemented. So we need to learn to relax in our daily practice of coding, and shift our confidence from coding everything to be rock solid to trusting ongoing process of change and evolution and improvement of the code base.

If we don’t learn to relax, we will put mountains of unused, unfit code in the way of our successors, team members, and future selves.

Premature abstraction is the root of many evils.

That hard-learned lesson applies to note-taking, which is learning-through-writing, as well:

Do not aim for perfection and stability and rigid robustness. Aim for flexibility and usefulnes.

Example to Illustrate the Point

I stumbled upon this short and sweet post, “Detecting Text Language with NLLanguageRecognizer in Swift” by Artem Mirzabekian, that teaches the reader how to infer the dominant language from a string. Two code samples, a bit of explanation for the types involved (that I skip because it’s part of the API and thus documentation), and useful warnings like “better not use too short a text, and prefer whole sentences to increase accuracy”.

Neat. I can see myself using this in the future. So I create a note; very basic.

Here it is, in full, for your reference:

# 202510230931 Detect dominant language from string
#naturallanguage

Apple's `NLLanguageRecognizer` can be used on a piece of text to detect
the dominant language in use. 

It works best with full sentences and if the text isn't too short:[#20251023lang][]

```swift
import NaturalLanguage

struct LanguageDetector {
    static func languageCode(for text: String) -> String? {
        let recognizer = NLLanguageRecognizer()
        recognizer.processString(text)
        if let language = recognizer.dominantLanguage {
            return language.rawValue // "en", "ru", "de", etc.
        }
        return nil
    }
}

The language recongizer exposes the confidence scores of detected languages:[#20251023lang][]

static func detectLanguage(for text: String) -> (code: String, confidence: Double)? {
    let recognizer = NLLanguageRecognizer()
    recognizer.processString(text)
    guard let language = recognizer.dominantLanguage else { return nil }
    let hypotheses = recognizer.languageHypotheses(withMaximum: 1)
    let confidence = hypotheses[language] ?? 0
    return (language.rawValue, confidence)
}

You could use that to discard auto-detected languages completely under a threshold of e.g. 0.5 confidence (pure chance), or ask the user to pick one if the top N matches are close together.

[#20251023lang]: Artem Mirzabekian: “Detecting Text Language with NLLanguageRecognizer in Swift”, 2025-10-08, https://livsycode.com/swift/detecting-text-language-with-nllanguagerecognizer-in-swift/ ```

Circling back to the beginning of this post, the title is a good-enough fit, but very general: “Detect dominant language from string”.

This is not a comprehensive list of ways to detect dominant languages across operating systems, programming languages, computing contexts, using local LLM’s or classic ML, cloud-service API’s, … – it’s just a rather simple Swift code sample for one of Apple’s frameworks.

I do not get more specific because even though there are many different ways in the world to detect languages, there’s currently only one relevant way for me. That’s as a Swift programmer on Apple platforms, where the Natural Language toolkit is a good fit.

I would not benefit from being more specific in the present – and maybe never, if it turns out I don’t ever detect languages from strings in my lifetime.

An obvious specificiation of the note content would be: “Detect dominant language from string in Swift with Apple NaturalLanguage”. But the appended part, “in Swift with Apple NaturalLanguage”, doesn’t help pick this one out in a sea of similar notes. There are no similar notes. In 2025, it’d be noise to me.

The #naturallanguage hashtag groups four notes at the moment:

• 202510230931 Detect dominant language from string
• 202107261124 Count word occurences in String
• 202001142100 Split text into sentences with NaturalLanguage toolkit
• 202001142058 Emotional sentiment or tone of sentences with NLTagger

“Split text into sentences” is worth specifying, because splitting with (some confidence) by regular expression is an obvious alternative. The specification of emotional sentiment using NLTagger doesn’t do much for me. It tells me at a glance that NLTagger is a thing, and being reminded of that may be useful, but I would be just as fine with removing that part. Premature optimization for a future that, since 2020, hasn’t manifested itself.

Keeping your titles accurate is important. They are your first contact with a note. You should spend some brain power now to make it easier for future-you do figure out whether a note is relevant: I only really work in one context at the moment, Swift and Apple frameworks, and it has been that way for 10+ years, so it’s perfectly fine to assume that I’ll be content with the title for 10 more. It could be wrong, but worrying about the accuracy for a future I cannot anticipate isn’t worth it. And living with a note for that time that reads something like

Detect dominant language on local computer from Swift.String with Apple NaturalLanguage toolkit on macOS, iOS, tvOS, visionOS, watchOS, not Linux, Windows

would not improve my life at all.

This is a riff on the mantra “all notes are malleable”, and by consequence that you can continuously improve your notes.

If I switch to become a web backend engineer using Go and need language detection there, I’ll probably stumble upon this Apple/Swift-related note and change it to avoid red herrings.

Until then, it’s fine. Don’t worry too much.