mojira.dev
MC-309839

Firework rocket tooltip does not show flight duration in multiple non-US languages

Steps to Reproduce:

  1. Launch Minecraft 26.3-snapshot-3 in Creative mode.

  2. Open the creative inventory.

  3. Hover over any pre-made firework rocket (any flight duration).

  4. Observe the tooltip.

Expected Result:
The tooltip should show "Flight Duration: X" (or equivalent translation) with the numeric value displayed.

Actual Result:
The tooltip shows only the label (e.g. "Flight Duration:") with no numeric value after it.


Additional Context:

This is not a translation issue. This is a source template issue.

I have tested this in 10 languages across 8 language families. All of them exhibit the exact same error:

LanguageResultChinese Simplified❌ MissingEnglish (UK)❌ MissingJapanese❌ MissingArabic❌ MissingPersian (Farsi)❌ MissingUkrainian❌ MissingKorean❌ MissingTamil❌ MissingTagalog❌ MissingYiddish❌ Missing

The error is identical in every language tested: the duration variable is completely absent from the tooltip. If this were individual translator mistakes, the errors would be varied and random. Instead, all 10 languages share the exact same missing variable — which rules out coincidence.

The only logical conclusion is that the Crowdin source string is missing the duration variable placeholder (e.g. {duration} or %s). Translators cannot add what is not provided in the source template.

Please investigate the Crowdin source template and fix the issue at its root.

Linked issues

Comments 7

Thank you for your report!
After consideration, the issue is being closed as Invalid.

This report does not describe a bug.

Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki

We recently added this placeholder as the flight duration was previously hardcoded and appended to the translated string in the code itself. Translations need to be updated, we do not track Crowdin issues here.

I would like to respectfully challenge the decision to close this as Invalid.

On July 11, ManosSef confirmed that the source string was missing a placeholder and said the issue would be resolved in the next snapshot. Now, bl4ckscor3 and the Triage Team have closed it as Invalid, stating that translations need to be updated on Crowdin.

These are two contradictory conclusions about the same issue.

My evidence shows that 10 languages across 8 language families all exhibit the exact same missing variable. This is not a translator mistake — it's a source template issue, as ManosSef already acknowledged.

If the fix is already in the source template, then the next snapshot should include the updated translations. But if the report is closed as Invalid, who is tracking whether the translations actually get updated?

I'm not asking for special treatment. I'm asking for a consistent answer: is this a valid bug that Mojang will ensure gets fixed, or is it entirely out of your scope?

Thank you for your time."

I would like to clarify the background of this report, because there seems to be some confusion.

This is a re-submission of MC-309819. That original report was initially closed as Invalid by ManosSef, who said it was a translation issue.

After I provided evidence from 10 languages across 8 language families, ManosSef replied on July 11 (see below) and acknowledged that the source string was missing a placeholder. He confirmed that the issue would be resolved in the next snapshot.

However, today the Triage Team and bl4ckscor3 closed this new report (MC-309839) as Invalid again, stating that translations need to be updated on Crowdin.

These two conclusions seem contradictory. The original report (MC-309819) was closed, and now this new report (MC-309839) is also closed. If the source template has been fixed as ManosSef said, that's great. But if the report is closed as Invalid, who is tracking whether the translations actually get updated?

I'm not trying to be difficult — I just want to make sure this issue doesn't fall through the cracks.

Original report: MC-309819

Thank you for your time."

I want to point out that this issue was already acknowledged by ManosSef in the original report (MC-309819).

On July 10 at 18:22, he replied:

"The affected string was changed to now use a placeholder variable when it didn’t have one before... The issue will be automatically resolved in the next snapshot for all languages that have made the appropriate change to their translation of the string."

That reply is in MC-309819, not in this new report. I'm mentioning it here because this new report (MC-309839) was submitted as a more organized version of the same issue, and it seems the Triage Team may not have seen ManosSef's confirmation.

If the fix is already in the source template as ManosSef confirmed, then this issue is effectively resolved for future snapshots. I just want to make sure this doesn't get lost in the process.

Original report: MC-309819

Thank you."

You misunderstood me entirely. I never said there was a mistake in the source string. I said that the source string had been updated, and therefore all languages would now have to change their own translations for it, which will only apply in the game in the next snapshot (that is what I meant by “automatically fixed”). Translations cannot be submitted for new or updated strings before they appear in the game, so it is completely expected that this “issue” is happening in the current snapshot.

There is no bug to fix here. This is a translation issue, and all languages will have to individually fix it for themselves on Crowdin.

You're right, I completely missed your point earlier. I re-read your reply and now I understand — this isn't a bug in the code, it's just that the translation hasn't caught up with the source string change yet, and it'll be fine in the next snapshot. I shouldn't have pushed back on this. Sorry about that, and thanks for being patient with me.

--LJL--

(Unassigned)

Confirmed

Text

26.3 Snapshot 3

Retrieved