Please add “commands.profile_fetch.id.success", as it also has “id” in inappropriate lower case.
(“Resolved profile for id %s: %s”)
I'm unable to find the string displayed in the launcher at the moment, (it was never displayed under common circumstances to begin with) but the mistake persists in the crowdin string.
relates to MCL-21769 (this is a new instance of the same mistake that was fixed for other strings)
Using a debug-stick to change the honey level seems to have the same effect as set-block, that is: Setting a hive to full with a debug stick, will create a honey block that will behave differently when ctrl-clicked than if it were first broken and replaced.
I cannot be sure when the behaviour changed, as I had been using a sticked hive for testing.
Edit: This doesn't quite seem to be quite complete. If the block is adjusted by a debug stick, or indeed by a bee, then ctrl+pickblock will behave as though the adjustment never happened. The only case where it preserves the honey level is if the block was broken and replaced in the way you suggest.
I will update the report
also applies to "Repair a damaged Wolf Armor using Armadillo Scutes" (advancements.husbandry.repair_wolf_armor.description) https://crowdin.com/editor/minecraft/10038/enus-enca?view=comfortable#5366252 note also that this string is misleading, as you actually have to fully repair the armor.
This and the existing ticket affect 1.20.5-pre1
My understanding, (and my experience pointing out language inconsistencies and mistakes on the feedback site) is that they are to be posted here as bugs, not there as feature requests.
@HubbiGamingTV the expected behaviour is not to keep teleporting again without leaving the portal. The expected behaviour would be for the portal animation not to play once through, or for it to play in reverse.
The problem is: it looks like you're going to teleport again when you aren't. (Even worse, the animation keeps getting wonkier until you can't even see what's going on.) The recommended solution is to make the visual cues match what's happening, not to change the teleportation behaviour.
So it should play the wind up animation when you first enter the portal, then, once you're through the portal, it should either not play an animation, or play a wind down animation (ending in no animation)
This also applies to today's new dynamic launcher string: game_faqs/Description for Account migration
Which reads:
%1$sWeb FAQ %2$shelp.minecraft.net%3$s.%4$s%5$s%6$sIMPORTANT:%7$s%8$s%9$s%10$sRequired migration began in March of 2022; currently, you have to migrate to a Microsoft Account if you wish to continue playing.%11$s%12$s
I disagree with adding a period to the end of each of these strings, as the majority aren't valid sentences.
In fact, the only valid full sentences are:
Some entities might have separate rules.
Angered neutral mobs stop being angry when the targeted player dies nearby.
Angered neutral mobs attack any nearby player, not just the player that angered them.
The rest lack a subject (because they refer back to the button/title)
of course "etc." has a period because it's an abbreviation, not because it happens to end the string
@ampolive I see that it's ambiguous what they meant, but I'm fairly confident that comment refers to the fact item names are title case. As in, those strings are literally the title of the inventory object. That wouldn't apply to sentence case advancement descriptions.
@Avoma I really think you are overcapitalizing. In English, the only words that need capital letters are:
The beginnings of sentences
Proper nouns ("Jack" or "Paris", but not "human" or "country") (though unlike in other languages, this does include the names of days, months, and a few other specific nouns)
Nationalities and languages like "British" or "Arabic" (even as adjectives)
Most words in titles
In minecraft specifically, the names of mobs and a few fictional materials are considered proper nouns.
Most of your capitalization recommendations however, seem to highlight random verbs and regular nouns for capitalization, even when not in titles. Error and status messages for example, need not be title-case.
"Realms" specifically, is an interesting case. I can't find the source right this second, but to my understanding, it only needs to be capitalized when referring to the name of the service, (because it's a proper noun in that case) and not when referring to an individual realm or collection of realms. So "Sign up for Realms" but "This will delete all of your realms"
Relates to MC-177133
To clarify, mco.download.cancelled and mco.upload.cancelled are realms strings.
These are tracked as REALMS-8860 (So this ticket should relate to that one)
@Bob Wu Why? Capitalizing all items would be completely inconsistent with the rest of the game, and English as a whole.
As noted by the bug marked as a duplicate, "copper block" isn't actually the name of any individual block in the game. (It's "block of copper")
a copper block may mean any block made of copper, rather than specifically the full blocks
but I agree simply "Apply wax to copper" and either "Scrape wax off of copper" or "Scrape wax from copper" would be clearest and simplest
*Note also:* these are the only advancement descriptions that end in "!". (Not worth its own ticket)
May also relate to MC-187546 or MC-226430 , as "Copper" should be lower case for consistency with other advancement descriptions.
If you wouldn't mind adding this information to the ticket body, including stating what the full text of these strings should be, that would likely simplify things for whoever fixes it.
The issues described by the two bugs are different, but the proposed solution to the other one would make this one irrelevant.
This appears to have been fixed