Like a lil feature comparison table with cute ticks and crosses.

Should include an example of how to use/setup the library, in addition to how to integrate it with the ANSI serializer

Platform builds don't use this version, so it's just confusing to have that version there, plus it's not really needed?

As was discussed in discord, it'd be nice to have some sort of form that's like I want to use adventure on [platform] on minecraft [version] and it gives you the correct repo/dependency to add.

So we can save manually trying to find typos :)

https://sphinxcontrib-spelling.readthedocs.io/en/latest/

We could probably set up a problem matcher for the output, if one doesn't already exist

Perhaps with a generic template for artifact information

Taking Paper as an example, it's not immediately obvious that you can use the Sound enum in place of a key when construction a sound. The documentation for native implementations could be improved to include more information about the standard implementations of various Adventure types.

Adventure has grown quite a few SPIs that platforms should be implementing. We should have a consolidated location where these are documented. So far, these are:

• the Providers for component serializers, to customize options
• the JSONComponentSerializer providers, for different component serializer implementations
• the DataComponentValueConverter.Provider interface, for controlling conversions between different data component value types
• the ClickCallback provider, to implement callbacks
• ComponentLoggerProvider to provide appropriate serializers for component logging

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• chore(deps): Update mcr.microsoft.com/vscode/devcontainers/python Docker tag to v1
• chore(deps): Lock file maintenance

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

It would be nice to split pointer docs into it's own page(s) with the following aspects:

• Usage of the API
• Standard, Adventure-provided pointers
• Community additions (if any, open for additions for platforms/etc) - is this even something we should encourage?

Probably not worth visiting until our docs are more thorough, but we should preserve a history of docs for different versions. The sphinxcontrib-versioning plugin might work for that.

https://sphinxcontrib-versioning.readthedocs.io/en/latest/index.html

Or, to phrase it another way, Components sent as messages to the server console (FabricServerAudiences#console()) are not rendered through the GlobalTranslator, but instead are rendered just as their language key. This differs from the behavior of other platforms like Paper and Sponge 7 that do perform this rendering.

MinecraftServer server = /* ... */;
FabricServerAudiences adventure = FabricServerAudiences.of(server);
TranslationRegistry registry = TranslationRegistry.create(Key.key("kyori", "test"));
registry.defaultLocale(Locale.ROOT);
registry.register("kyori.test", Locale.ROOT, new MessageFormat("Hello, world!"));
adventure.console().sendMessage(Component.translatable("kyori.test"));
// Expected output: "Hello, world!"
// Actual output: "kyori.test"

I did poke around at the library code but I'm not sure what's causing this. Implementation looks pretty similar to Paper's and I don't immediately see any logical errors. Could be related to using the mod as jar-in-jar but then, the global translator works for other purposes like sending actual chat messages to players, so 🤷🏻‍♀️

Using adventure 4.13.1, adventure-platform-fabric 5.8.0, fabric-api 0.78.0+1.19.4, & fabric-server-mc.1.19.4-loader.0.14.19-launcher.0.11.2.jar

On this page in the example you're unable to see the
5 in Formatter.choice("choice", 5)); due to the Copy to clipboard covering it

There's currently nothing on adventure-nbt, so everything needs to be covered

Key points

• Immutability
• Serializing to binary format
• Working with string format -- in its various iterations

Possible examples:

• Replacing emojis
• Mentioning users
• Making links clickable

The alias <r> for <reset> remains in its literal form.

https://github.com/marketplace/actions/crowdin-action
https://www.sphinx-doc.org/en/master/usage/advanced/intl.html

We currently reference a bunch of Adventure classes, which have additional context in the JD. It would be helpful to link directly to those classes. There are a couple extensions for that:

• https://github.com/bluekeyes/sphinx-javalink
• https://github.com/12awsomeman34/sphinx-JDLinker

These both have some limitations that make them a bit awkward -- but we could tweak whichever one to produce something fully suited to our needs.

Our current approach for documentation works okay, but once we begin development on (and release) 5.0.0 we will need to have two versions of documentation live - 4.x and 5.x. How can/should we do this?

Points to cover

• extend .Single
• how only the terminal methods are overridden
• Use in cross-platform plugins

Example use cases

public class GameTeam implements ForwardingAudience {
  private final List<GamePlayer> players = new ArrayList<>();

  // ....

  @Override
  public @NonNull Iterable<? extends GamePlayer> audiences() {
    return this.players;
  }
}

The <reset> tag for MiniMessages has an alias r in the docs, which was most likely removed.

https://docs.advntr.dev/minimessage/format.html#reset

We have a basic localization system within Adventure, using TranslationRegistry

There should be a documentation page explaining it, how it interacts with vanilla translations, and its limitations.

Limitations include:

• no specialized number formatting
• relies on client sending its language to the server
• plural handling

This could mention moonshine, and potentially whatever is added to MiniMessage for localization

See https://minecraft.fandom.com/wiki/Raw_JSON_text_format#Component_resolution

It seems like there is a big gap in understanding with a lot of users new to adventure, who have trouble with the concepts of chat components, having only been familiar with the legacy section-symbol system. It would be helpful to explain what components are and some of their key characteristics, ideally with some graphics. Here's a rough outline of what I'm imagining:

1. What is a component?
   1. structured representation: the text form represents the data structure, rather than being marked-up text
   2. different types of content
   3. tree structure: see style
   4. appending: children in the tree (visual here?)
2. Where did components come from?/Why do we want to use components?
   1. history: 1.7.2 introduction, 1.13 most of the server converted to use them, 1.16 client text renderer converted
   2. originally: a way to be more explicit about links and other rich styling
   3. references:
      • https://gist.github.com/Dinnerbone/5631634
      • https://gist.github.com/Dinnerbone/6488256
      • https://bugs.mojang.com/browse/MC-190605?focusedCommentId=993040
   4. examples of quirks/limitations of legacy text, and how chat components resolve those issues
3. Style in components
   1. tree style
   • [visual] show a component tree with styles, show how they're inherited, and piecewise overridden
   2. attributes can exist together, no 'magical' reseting like legacy strings had
   3. more attributes can be added -- see font or RGB colour
4. Examples
   1. Some side-by-side tables of json, adventure representation, and in-game visuals?
5. History of components (can it be merged with 2?)
   1. version-by-version breakdown of what has been added/changed

Right now, users report that there isn't really a clear 'getting started' guide that provides an overview of how to dive into the API.

It would be nice to provide some sort of linear guide, targeting only native platforms, explaining how to:

• Create a component
• Send the component to a user
• Create a component from a configuration using MiniMessage
• maybe some other things?

How much of this can be done in our own docs without making too many assumptions about platforms? How much should be, we link to platforms for their dogumentation instead?

According to MC-146721, stereo sounds won't drop off whereas mono sounds will. This should be mentioned in the docs for sounds in order to prevent confusion with the new emitter system.

Currently, the examples for each MiniMessage tag are produced manually by entering the MiniMessage string into a game instance and taking a screenshot.

We should be able to rig something up to generate this automatically, taking in a properties file of IDs and MiniMessage strings to generate and running the Minecraft client's font renderer headlessly to produce images from this file.

There are some commonly asked questions relating to specific implementation choices and common applications of adventure that don't currently fit anywhere better. As much as I've historically been a bit against an FAQ page as a dumping ground for mismatched topics, it would be useful to cover a few things:

• build issues: link to maven/gradle shading documentation (maybe in less detail than the discord wall of text
• explain our recommended approach for converting legacy strings to MiniMessage strings
• why does x not exist? it's not been contributed/community library
• info about working with bukkit's PlaceholderAPI?
• maybe some commentary about issues with monolithic 'client's -- tell people to try with Vanilla