i18nspector(1)

📦
version 0.27.2 · 3 versions
, in ubuntu resolute, ubuntu stonking

🌸 i18nspector 🌸

okay so bestie, welcome to the i18nspector(1) page from your General Commands Manual — it's the gettext-checking tool and honestly it's kind of a big deal 💅

✨ SYNOPSIS ✨

i18nspector [options] file [file …]

💖 DESCRIPTION 💖

i18nspector is that girl who checks your translation templates (POT), your message catalogues (PO) and your compiled message catalogues (MO) files for common problems. no cap, she will find the mess 🙈

these files are used by the GNU gettext translation functions and tools across so many different development environments — like, everywhere. she's the vibe check your localization pipeline has been begging for 🦋

💅 OPTIONS 💅

  • -l lang, --language lang — assume this language, bestie. lang should be a 2- or 3-letter ISO 639 language code, and it can also have an underscore plus a 2-letter ISO 3166 territory code tacked on the end 🎀
  • --unpack-deb — allow unpacking Debian (binary or source) packages. yes, she'll crack those open for you 💀
  • -j n, --jobs n — use n processes in parallel. n can be a positive integer, or auto to determine the number automatically ✨ the default is to use only a single process (she's lowkey chill like that)
  • -h, --help — show help message and exit 🫶
  • --version — show version information and exit ⭐

🎀 OUTPUT FORMAT 🎀

every single reported problem uses this format, no exceptions:

code: file: tag [extra]

and here's the breakdown, because we love a legend:

  • code is a letter indicating the type of the message: E (error), W (warning), I (informative message), or P (pedantic message) 👑
  • tag is a name of the problem that was discovered 🔍
  • extra can contain additional information about the problem 💬

🏷️ TAGS 🏷️

this is the main character section, fr fr. every tag, every detail, every severity. buckle up 🧚

ancient-date

the date refers to the time before the first GNU gettext release. as such, it's extremely unlikely to be correct 😭

References:

Severity, certainty: normal, certain

arithmetic-error-in-plural-forms

computing a plural form value triggers division by zero or integer overflow. this normally indicates an error in the plural form expression 💀

References:

Severity, certainty: serious, possible

arithmetic-error-in-unused-plural-forms

computing a plural form value triggers division by zero or integer overflow. (but there are no translated messages which use plural forms.) this normally indicates an error in the plural form expression 🙈

References:

Severity, certainty: normal, possible

boilerplate-in-content-type

the Content-Type header field contains xgettext boilerplate. it should be in the form text/plain; charset=encoding 🎀

References:

Severity, certainty: important, certain

boilerplate-in-date

the date header field contains xgettext boilerplate. the date format should be YYYY-MM-DD hh:mm+ZZzz, e.g. 2011-11-05 10:14+0100 ✨

Severity, certainty: normal, certain

boilerplate-in-initial-comments

the initial comments contain xgettext or msginit boilerplate 🫶

References:

Severity, certainty: minor, possible

boilerplate-in-language-team

the Language-Team header field contains xgettext boilerplate. it should contain English name of the language, and the email address or homepage URL of the language team 💌

References:

Severity, certainty: minor, certain

boilerplate-in-last-translator

the Last-Translator header field contains xgettext boilerplate. it should contain the last translator's name and email address 🌸

References:

Severity, certainty: normal, certain

boilerplate-in-project-id-version

the Project-Id-Version header field contains xgettext boilerplate. it should contain the name and the version of the package 📦

References:

Severity, certainty: minor, certain

boilerplate-in-report-msgid-bugs-to

the Report-Msgid-Bugs-To header field contains xgettext boilerplate. it should contain an email address or URL where one can report bugs in the untranslated strings 🐛

References:

Severity, certainty: normal, certain

broken-encoding

header fields and messages contained by this file couldn't be decoded to Unicode. the usual cause of this is incorrect or missing encoding declaration 😵💫

note that in the absence of encoding declaration, i18nspector assumes ASCII encoding.

References:

Severity, certainty: serious, possible

c-format-string-argument-type-mismatch

there's a type mismatch between a C format argument in msgid and the corresponding format argument in msgid_plural; or between a C format argument in msgstr and msgid; or between a C format argument in msgstr[N] and corresponding msgid or msgid_plural 💀

References:

Severity, certainty: serious, possible

c-format-string-error

a C format string could not be parsed. she literally could not read it 😭

References:

Severity, certainty: serious, possible

c-format-string-excess-arguments

a C format string for msgid consumes more arguments than msgid_plural; or msgstr consumes more arguments than msgid; or msgstr[N] consumes more arguments than corresponding msgid or msgid_plural 🔥

References:

Severity, certainty: serious, possible

c-format-string-missing-arguments

a C format string for msgid consumes fewer arguments than msgid_plural; or msgstr consumes fewer arguments than msgid; or msgstr[N] consumes fewer arguments than corresponding msgid or msgid_plural 👀

note that in some languages, the commonly used Plural-Forms expression evaluates to the same value for n=1 and n=21, n=31, and so on. take this Serbian translation for example:
Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;
...
msgid "one byte"
msgid_plural "%d bytes"
msgstr[0] "%d bajt"
msgstr[1] "%d bajta"
msgstr[2] "%d bajtova"

here %d should not be replaced with the spelled-out form jedan. either %d should be kept, or the Plural-Forms expression should be amended, so that there is a special case for n=1:

Plural-Forms: nplurals=4; plural=n==1 ? 3 : n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2
...
msgid "one byte"
msgid_plural "%d bytes"
msgstr[0] "%d bajt"
msgstr[1] "%d bajta"
msgstr[2] "%d bajtova"
msgstr[3] "jedan bajt"

References:

Severity, certainty: serious, possible

c-format-string-non-portable-conversion

a C format string uses a conversion specified or length modifier, for which a more portable replacement exists ✨ here's the tea:

  • for integer conversions (%d, %i, %o, %u, %x, and %X), use the ll length modifier instead of L or q.
  • for floating-point conversions (%a, %A, %e, %E, %f, %F, %g, and %G), don't use the l length modifier.
  • use the z length modifier instead of Z.
  • use %lc instead of %C.
  • use %ls instead of %S.

References:

Severity, certainty: pedantic, possible

c-format-string-redundant-flag

a C format string includes a redundant character flag. either it's a duplicate, or it has no effect 🙃

  • the + flag overrides the space flag.
  • the - flag overrides the 0 flag.
  • if a precision is given, the 0 flag has no effect on integer conversions (%d, %i, %o, %u, %x, and %X).

References:

Severity, certainty: pedantic, possible

codomain-error-in-plural-forms

either a plural form value is outside the declared range, or some values within the declared range can never be reached. this normally indicates an error in the plural form expression 🔍

References:

Severity, certainty: serious, certain

codomain-error-in-unused-plural-forms

either a plural form value is outside the declared range, or some values within the declared range can never be reached. (but there are no translated messages which use plural forms.) this normally indicates an error in the plural form expression 🫠

References:

Severity, certainty: normal, certain

conflict-marker-in-header-entry

the header contains a conflict marker (#-#-#-#-# … #-#-#-#-#). the conflict will have to be resolved manually 😤

References:

Severity, certainty: serious, certain

conflict-marker-in-translation

one of the translated messages appear to contain a conflict marker (#-#-#-#-# … #-#-#-#-#). the conflict will have to be resolved manually 😤

References:

Severity, certainty: serious, possible

conflicting-message-flags

two flags with conflicting meanings are associated with one of the messages 🚩

References:

Severity, certainty: important, possible

date-from-future

the date refers to the future. as such, it's extremely unlikely to be correct 🔮

Severity, certainty: normal, certain

distant-header-entry

the header entry in this file is preceded by other entries. the header entry should be always the first one 👑

Severity, certainty: important, certain

duplicate-flag-for-header-entry

multiple identical flags are associated with the header entry 🫠

Severity, certainty: minor, certain

duplicate-header-entry

this file contains multiple header entries 😵

Severity, certainty: serious, certain

duplicate-header-field

this file contains multiple header fields of the same name 👯

Severity, certainty: minor, wild-guess

duplicate-header-field-content-transfer-encoding

bestie, this file has multiple Content-Transfer-Encoding header fields. one is the vibe, two is a situation. 🙈

  • Severity, certainty: pedantic, certain

duplicate-header-field-content-type

yep, there's more than one Content-Type header field up in here. pick a lane, file. 💅

  • Severity, certainty: serious, certain

duplicate-header-field-date

this file has multiple date header fields of the same name. like, we get it, time exists. ⏰

  • Severity, certainty: normal, certain

duplicate-header-field-language

multiple Language header fields?? the file is having a whole identity crisis. 🌈

  • Severity, certainty: important, certain

duplicate-header-field-language-team

more than one Language-Team header field. one team per file, that's the rule. 🫶

  • Severity, certainty: normal, certain

duplicate-header-field-last-translator

multiple Last-Translator header fields. who translated it last? apparently everyone. 😭

  • Severity, certainty: normal, certain

duplicate-header-field-mime-version

this file contains multiple MIME-Version header fields. lowkey excessive ngl.

  • Severity, certainty: pedantic, certain

duplicate-header-field-plural-forms

multiple Plural-Forms header fields. plural forms are already a lot, and now there's duplicates? not the moment. 💀

  • Severity, certainty: serious, certain

duplicate-header-field-project-id-version

this file contains multiple Project-Id-Version header fields. okay project, we know your name and version, relax. ✨

  • Severity, certainty: minor, certain

duplicate-header-field-report-msgid-bugs-to

multiple Report-Msgid-Bugs-To header fields. where do the bugs go?? contradictory. 🐛

  • Severity, certainty: normal, certain

duplicate-header-field-x-poedit

this file contains multiple X-Poedit-* header fields. poedit said double it and give it to the next person. 🎀

  • Severity, certainty: normal, certain

duplicate-message-definition

this file contains multiple definitions of the same message. iconic of it to define itself twice, but no. 🔥

  • Severity, certainty: serious, certain

duplicate-message-flag

one of the messages has multiple identical flags attached to it. same flag twice = not serving. 👑

  • Severity, certainty: minor, certain

empty-file

this file doesn't contain any messages. it's giving absolutely nothing, and not in a cute way. 🦋

  • Severity, certainty: normal, certain

empty-msgid-message-with-plural-forms

so the message with an empty msgid contains plural forms. those messages are reserved by GNU gettext for header entries, and your code should not call ngettext("", …). periodt. 🚫

  • Severity, certainty: serious, certain

empty-msgid-message-with-source-code-references

the message with empty msgid contains plural forms. these messages are reserved by GNU gettext for header entries, so your code should not call gettext(""). don't do it bestie.

  • Severity, certainty: serious, possible

encoding-in-language-header-field

the language header field has an encoding declaration in it. that info does not belong in this field, so. take it out. 🧚

References:

fuzzy-header-entry

the header entry is marked as fuzzy. for compatibility with very old (<< 0.11) msgfmt(1) versions — the ones that didn't support fuzzy header entries at all — it shouldn't be marked as such. ancient-tech respect. 🏺

References:

inconsistent-leading-newlines

some strings in an entry start with a newline, some don't. either all of them start with a newline, or none of them do. consistency is the whole vibe check here. 🌸

  • Severity, certainty: important, possible

inconsistent-number-of-plural-forms

the number of plural forms in a message definition doesn't match the number of plural forms declared in another message definition. they're not matching and it shows. 😭

References:

inconsistent-trailing-newlines

some strings in an entry end with a newline, some don't. either all of them end with a newline, or none of them do. pick one, bestie. ✨

  • Severity, certainty: important, possible

incorrect-number-of-plural-forms

the number of plural forms in a message definition doesn't match the number declared in the header. the header said one thing, the messages said another. 💀

References:

invalid-content-transfer-encoding

the value of the Content-Transfer-Encoding header field is invalid. it should be 8bit. that's the only correct answer here. 🎀

References:

invalid-content-type

the value of the Content-Type header field is invalid. it should be in the form text/plain; charset=encoding. that's the format, no deviations. 📝

References:

invalid-date

the date is invalid, or it's in an invalid format. it should be YYYY-MM-DD hh:mm+ZZzz, like 2011-11-05 10:14+0100. yes, exactly like that. 🗓️

References:

invalid-language

the Language header field couldn't be parsed, or it contains a language nobody recognizes. mystery language era. 🌍

References:

invalid-language-team

the Language-Team header field contains an e-mail address that uses a reserved domain name, or a partially qualified domain name. not a real reachable address, basically. 🚫

References:

invalid-last-translator

the Last-Translator header field could neither be parsed as an e-mail, or the e-mail address uses a reserved domain name, or a partially qualified domain name. any of those three and it's a no from i18nspector. 💅

References:

invalid-mime-version

the value of the MIME-Version header field is invalid. it should be 1.0. one point oh. that's it. ⭐

References:

invalid-mo-file

this file couldn't be parsed as a MO file. it tried, it failed, we move. 😭

  • Severity, certainty: serious, certain

invalid-range-flag

a range: flag couldn't be parsed, or the range it designates contained fewer than two numbers. the syntax is range: min..max, where both values are non-negative integers. two numbers minimum, non-negative, no exceptions. 🔢

References:

invalid-report-msgid-bugs-to

the Report-Msgid-Bugs-To header field could neither be parsed as an e-mail nor as a URL, or the e-mail address uses a reserved domain name, or a partially qualified domain name. so many ways to be wrong and it found one. 🐛

References:

language-disparity

the language of this file got declared in multiple places, but the declarations don't match. two sources of truth and they're beefing. 🌈

  • Severity, certainty: normal, possible

language-team-equal-to-last-translator

the Language-Team and Last-Translator header fields contain the same e-mail address. same person, two hats. 🎩

  • Severity, certainty: minor, possible

language-variant-does-not-affect-translation

the Language header field contains a variant designator that isn't relevant for the message translation. extra detail that does nothing for the translation, so it's just kinda there. 🙈

References:

leading-junk-in-plural-forms

the Plural-Forms header field has unexpected text sitting before the nplurals= string.

the GNU gettext runtime ignores that leading junk, but other header parsers might be less liberal in what they accept. so it's fine until it very much isn't. ⚠️

  • Severity, certainty: important, certain

malformed-xml

the original string or the translated string contains an XML fragment that is not well-formed. the tags aren't tagging. 🧚

References:

no-content-transfer-encoding-header-field

the Content-Transfer-Encoding header field doesn't exist at all. it should be set to 8bit. it's just missing, bestie. 😭

References:

no-content-type-header-field

the Content-Type header field doesn't exist. it should be set to text/plain; charset=encoding.

heads up: when there's no encoding declaration at all, i18nspector assumes ASCII encoding. noted. 📌

References:

no-date-header-field

the date header field doesn't exist. no timestamp, no vibes. 🕰️

References:

no-language-header-field

the Language header field doesn't exist. we literally don't know what language this is. 💀

References:

no-language-team-header-field

the Language-Team header field does not exist. it should contain the English name of the language, plus the email address or homepage URL of the language team. so, like, who even is this team. 🫶

References:

no-last-translator-header-field

the Last-Translator header field doesn't exist. it should contain the last translator's name and email address. credit where credit is due, bestie. 👑

References:

no-mime-version-header-field

the MIME-Version header field doesn't exist. it should be set to 1.0. one line, one number, and it's not there. 🎀

References:

no-package-name-in-project-id-version

Okay so the Project-Id-Version header field is giving… nothing? It doesn't appear to contain any name 😭 and bestie, it's supposed to hold both the name and the version of the package. Like, the whole point.

References:

Severity, certainty: minor, possible

no-plural-forms-header-field

The Plural-Forms header field straight up does not exist 🙈 even though some of the messages use plural forms. (Although — plot twist — none of them have actually been translated yet, so it's lowkey chill.) Still flagged tho.

References:

Severity, certainty: minor, certain

no-project-id-version-header-field

The Project-Id-Version header field does not exist. It's supposed to contain the name and the version of the package, and rn it contains… silence 💀

References:

Severity, certainty: minor, certain

no-report-msgid-bugs-to-header-field

The Report-Msgid-Bugs-To header field does not exist, or it exists but it's empty (the audacity ✋). It should contain an email address or a URL where someone can report bugs in the untranslated strings. Give the people a place to yell, bestie 🫶

References:

Severity, certainty: normal, certain

no-required-plural-forms-header-field

The Plural-Forms header field does not exist, and this time it's not a drill — some of the translated messages use plural forms. So yeah, this one's actually needed.

References:

Severity, certainty: serious, certain

no-version-in-project-id-version

The Project-Id-Version header field doesn't appear to contain any version. It should contain both the name and the version of the package. Name only? Not the vibe. It's giving incomplete 🎀

References:

Severity, certainty: pedantic, possible

non-ascii-compatible-encoding

This file uses an encoding that is not compatible with ASCII. That's it, that's the whole thing, and it's kind of a big deal.

Severity, certainty: serious, certain

non-portable-encoding

This file uses an encoding that is not widely supported by software. Not portable, not slay. Proceed with caution.

References:

Severity, certainty: important, certain

os-error

An input/output error or another operating system error happened while checking this file. The OS said "not today" 😭

Severity, certainty: serious, certain

partially-translated-message

Translation is missing for some plural forms of a message. Half a translation is not a whole translation, bestie.

Severity, certainty: serious, possible

perl-brace-format-string-error

A Perl format string could not be parsed. It's giving unparseable 🔥

References:

Severity, certainty: serious, possible

perl-brace-format-string-missing-argument

Okay so a Perl format string for msgid doesn't use a named argument that is used in msgid_plural; or msgstr doesn't use a named argument that is used in msgid; or msgstr[N] doesn't use a named argument that is used in the corresponding msgid or msgid_plural.

Now the important bit — in some languages, the commonly used Plural-Forms expression evaluates to the same value for n=1 and n=21, n=31, and so on. Take this Serbian translation for example:

Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;
...
msgid "one byte"
msgid_plural "{n} bytes"
msgstr[0] "{n} bajt"
msgstr[1] "{n} bajta"
msgstr[2] "{n} bajtova"

Here {n} should not be replaced with the spelled-out form jedan. Either {n} should be kept, or the Plural-Forms expression should be amended, so that there is a special case for n=1:

Plural-Forms: nplurals=4; plural=n==1 ? 3 : n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2
...
msgid "one byte"
msgid_plural "{n} bytes"
msgstr[0] "{n} bajt"
msgstr[1] "{n} bajta"
msgstr[2] "{n} bajtova"
msgstr[3] "jedan bajt"

References:

Severity, certainty: serious, possible

perl-brace-format-string-unknown-argument

A Perl format string for msgid uses a named argument that isn't used in msgid_plural; or msgstr uses a named argument that isn't used in msgid; or msgstr[N] uses a named argument that isn't used in the corresponding msgid or msgid_plural. This indicates that the conversion would try to consume an argument that weren't supplied. Rude of it, honestly.

References:

Severity, certainty: serious, possible

python-brace-format-string-argument-type-mismatch

There's a type mismatch between a Python format argument in msgid and the corresponding format argument in msgid_plural; or between a Python format argument in msgstr and msgid; or between a Python format argument in msgstr[N] and msgid or msgid_plural. Types didn't match, they're not compatible, it's not gonna work out 💔

References:

Severity, certainty: serious, possible

python-brace-format-string-error

A Python format string could not be parsed. That's the whole saga.

References:

Severity, certainty: serious, possible

python-brace-format-string-missing-argument

A Python format string for msgid doesn't use a named argument that is used in msgid_plural; or msgstr doesn't use a named argument that is used in msgid; or msgstr[N] doesn't use a named argument that is used in the corresponding msgid or msgid_plural.

And here's the lil linguistics moment again: in some languages, the commonly used Plural-Forms expression evaluates to the same value for n=1 and n=21, n=31, and so on. Take this Serbian translation for example:

Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;
...
msgid "one byte"
msgid_plural "{n} bytes"
msgstr[0] "{n} bajt"
msgstr[1] "{n} bajta"
msgstr[2] "{n} bajtova"

Here {n} should not be replaced with the spelled-out form jedan. Either {n} should be kept, or the Plural-Forms expression should be amended, so that there is a special case for n=1:

Plural-Forms: nplurals=4; plural=n==1 ? 3 : n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2
...
msgid "one byte"
msgid_plural "{n} bytes"
msgstr[0] "{n} bajt"
msgstr[1] "{n} bajta"
msgstr[2] "{n} bajtova"
msgstr[3] "jedan bajt"

References:

Severity, certainty: serious, possible

python-brace-format-string-unknown-argument

A Python format string for msgid uses a named argument that isn't used in msgid_plural; or msgstr uses a named argument that isn't used in msgid; or msgstr[N] uses a named argument that isn't used in the corresponding msgid or msgid_plural. This indicates that the conversion would try to consume an argument that weren't supplied. Mystery argument, uninvited, iconic behavior.

References:

Severity, certainty: serious, possible

python-format-string-argument-number-mismatch

A Python format string for msgid consumes more arguments than msgid_plural; or msgstr consumes more arguments than msgid; or msgstr[N] consumes more arguments than msgid or msgid_plural. Somebody's eating more than their share 🍓

And fr fr — Python, unlike C, requires that all unnamed arguments must be consumed during conversion. No leftovers allowed.

References:

Severity, certainty: serious, possible

python-format-string-argument-type-mismatch

There's a type mismatch between a Python format argument in msgid and the corresponding format argument in msgid_plural; or between a Python format argument in msgstr and msgid; or between a Python format argument in msgstr[N] and msgid or msgid_plural.

References:

Severity, certainty: serious, possible

python-format-string-error

A Python format string could not be parsed. The parser looked at it and said "nope" 💅

References:

Severity, certainty: serious, possible

python-format-string-missing-argument

A Python format string for msgid doesn't use a named argument that is used in msgid_plural; or msgstr doesn't use a named argument that is used in msgid; or msgstr[N] doesn't use a named argument that is used in the corresponding msgid or msgid_plural.

Okay so same plot as before: in some languages, the commonly used Plural-Forms expression evaluates to the same value for n=1 and n=21, n=31, and so on. Take this Serbian translation for example:

Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;
...
msgid "one byte"
msgid_plural "%(n)d bytes"
msgstr[0] "%(n)d bajt"
msgstr[1] "%(n)d bajta"
msgstr[2] "%(n)d bajtova"

Here %d should not be replaced with the spelled-out form jedan. Either %d should be kept, or the Plural-Forms expression should be amended, so that there is a special case for n=1:

Plural-Forms: nplurals=4; plural=n==1 ? 3 : n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2
...
msgid "one byte"
msgid_plural "%(n)d bytes"
msgstr[0] "%(n)d bajt"
msgstr[1] "%(n)d bajta"
msgstr[2] "%(n)d bajtova"
msgstr[3] "jedan bajt"

References:

Severity, certainty: serious, possible

python-format-string-multiple-unnamed-arguments

A Python format string uses multiple unnamed arguments (such as %d). The translator might need to reorder the arguments to properly translate the message, but this is not possible with unnamed arguments. Named arguments (such as %(num)d) should be used instead. Name your args, bestie, it's the polite thing to do 🌸

References:

Severity, certainty: serious, possible

python-format-string-obsolete-conversion

bestie your Python format string is out here using an obsolete conversion specifier 💀 it's giving 2009

  • use %d instead of %u, that's literally the whole fix

References:

Severity, certainty: pedantic, possible

python-format-string-redundant-flag

your Python format string has a redundant character flag, bestie 🙈 either it's a straight-up duplicate or it's just… doing nothing:

  • the + flag overrides the space flag
  • the - flag overrides the 0 flag
  • if a precision is given, the 0 flag has no effect on integer conversions (%d, %i, %o, %u, %x, and %X)

References:

Severity, certainty: pedantic, possible

python-format-string-redundant-length

a redundant length modifier is hanging out in your Python format string 😭 and here's the tea: length modifiers (h, l, or L) have no effect in Python. none. zero. nada.

References:

Severity, certainty: pedantic, possible

python-format-string-redundant-precision

a C format string includes precision that has no effect on the conversion. that precision is not serving, it's just vibing ✨

References:

Severity, certainty: pedantic, possible

python-format-string-unknown-argument

okay this one's a little messy so let's break it down 💅

  • a Python format string for msgid uses a named argument that isn't used in msgid_plural
  • or msgstr uses a named argument that isn't used in msgid
  • or msgstr[N] uses a named argument that isn't used in the corresponding msgid or msgid_plural

what does that mean? it means the conversion would try to consume an argument that wasn't supplied. not the vibe. not the move.

References:

Severity, certainty: serious, possible

python-format-string-unnamed-plural-argument

a Python format string is using an unnamed argument (like %d) in the context of plural forms. the translator might want to not use the numeric argument in the singular form — totally valid — but that's just not possible if the argument is unnamed, because Python, unlike C, requires that all unnamed arguments must be consumed during conversion. no skipping, no opting out 🫠

so: named arguments (like %(n)d) should be used instead. periodt.

References:

Severity, certainty: wishlist, possible

qt-plural-format-mistaken-for-c-format

a c-format flag is associated with the message, but bestie… qt-plural-format should be used instead 🌸

here's why: the only C format directive that the message uses is %n. and using %n all by itself in a C format string is very atypical. suspicious, even. it's giving identity crisis.

References:

Severity, certainty: important, possible

range-flag-without-plural-string

a range: flag is associated with a message that doesn't have a plural string 😭 and range: flags only make sense for translations involving plural forms. it's a flag with nothing to do, standing in the corner at the party.

References:

Severity, certainty: normal, certain

redundant-message-flag

a flag associated with one of the messages is redundant, because it's implied by another flag. two flags, one job 💅

References:

Severity, certainty: pedantic, certain

stray-header-line

the header contains a line that does not belong to any header field. it's just… there. a stray. an orphan. 🙈

heads up: RFC-822-style folding of long headers is not supported. so don't try it.

References:

Severity, certainty: important, certain

stray-previous-msgid

the message entry contains annotations about previous untranslated string (#| msgid ...), even though the message is not marked as fuzzy. those annotations are only useful for fuzzy messages, and should be removed when unfuzzying. it's giving leftovers in the fridge 🥴

References:

Severity, certainty: minor, certain

syntax-error-in-plural-forms

the value of the Plural-Forms header field could not be parsed 😭 it should be in the form nplurals=n; plural=expression.

References:

Severity, certainty: serious, certain

syntax-error-in-po-file

this file couldn't be parsed as a PO file 💀 in some rare cases this is due to incorrect or missing encoding declaration.

References:

Severity, certainty: serious, possible

syntax-error-in-unused-plural-forms

the value of the Plural-Forms header field could not be parsed 😭 (but plot twist: there are no translated messages which use plural forms.) it should be in the form nplurals=n; plural=expression.

References:

Severity, certainty: important, certain

trailing-junk-in-plural-forms

the Plural-Forms header field contains unexpected text after the plural expression. extra. uninvited. 👀

the GNU gettext runtime ignores such trailing junk, but other header parsers might be less liberal in what they accept. so like, don't rely on everyone being this chill.

Severity, certainty: important, certain

translation-in-template

the PO template file contains a translated message 🚨 a template is supposed to be untranslated, bestie. that's its whole thing.

Severity, certainty: minor, certain

unable-to-determine-language

i18nspector was unable to determine the language of this file 😭 and the absence of this information will prevent it from performing further checks. so it's not just a little oopsie, it's a whole roadblock.

Severity, certainty: normal, wild-guess

unexpected-flag-for-header-entry

an unexpected flag is associated with the header entry. the only flag that makes sense for the header entry is fuzzy. everything else is just cosplaying 🙈

References:

Severity, certainty: normal, possible

unknown-encoding

this file declares an encoding that couldn't be recognized by i18nspector. it might be a typo 👀 and heads up: the absence of encoding information will prevent i18nspector from performing further checks.

Severity, certainty: important, possible

unknown-file-type

the file format of this file couldn't be recognized. and honestly? it might be a bug in i18nspector itself 💀 not you, us.

Severity, certainty: normal, wild-guess

unknown-header-field

the header field name is unknown to i18nspector. it might be a typo or a capitalization error — and yes, header field names are case-sensitive, so Plural-Forms and plural-forms are not the same girl 💅

References:

Severity, certainty: minor, wild-guess

unknown-message-flag

an unknown flag is associated with one of the messages. it might be a typo 🫠

References:

Severity, certainty: normal, wild-guess

unknown-poedit-language

the language declared in X-Poedit-Language couldn't be recognized. it might be a bug in i18nspector 👀

Severity, certainty: minor, wild-guess

unrepresentable-characters

the declared encoding cannot represent all characters commonly used in this language. and that is a strong indication that the declared encoding is incorrect. like, screaming-in-caps strong.

Severity, certainty: serious, possible

unusual-character-in-header-entry

the header entry contains an unusual character 👀 this is usually an indication of an encoding problem, such as:

  • using ISO 2022 escape sequences, or
  • using UTF-8 despite declaring an 8-bit encoding

References:

Severity, certainty: important, certain

unusual-character-in-translation

one of the translated messages contains an unusual character 👀 this is usually an indication of an encoding problem, such as:

  • using ISO 2022 escape sequences, or
  • using UTF-8 despite declaring an 8-bit encoding

References:

Severity, certainty: important, possible

unusual-plural-forms

the Plural-Forms declaration is incorrect (or unusual), according to i18nspector's linguistic data. it's not like other girls and not in a slay way 🫠

Severity, certainty: serious, possible

unusual-unused-plural-forms

the Plural-Forms declaration is incorrect (or unusual), according to i18nspector's linguistic data. (but there are no translated messages which use plural forms — so it's a problem that's just… sitting there unused.)

Severity, certainty: normal, possible

See also ✨

that's a wrap bestie, and if you made it all the way to the end of this absolute doorstop of a manpage, you're genuinely the main character 💖 this whole thing was i18nspector 0.27.2, dated 2026-01-13 — go forth and make your PO files iconic, no cap 🎀🦋👑

📦 where this page comes from