Merge Kotlin and Kotlin multiplaform into one

[bruno-garcia]

SDK

Kotlin Multiplatform SDK

Description

We have two entries on the docs for Kotlin:

It takes space in the landing page as well as the drop down.

Kotlin docs is only a landing page to route the reader to either Android, Java or Kotlin Multi-platform: https://docs.sentry.io/platforms/kotlin/

It does that while showing sentry-java information the right side.

Kotlin extensions, which lives under the Java docs, apply to Kotlin in general, including KMP.
https://docs.sentry.io/platforms/java/enriching-events/scopes/#kotlin-coroutines

Kotlin itself has one doc: https://kotlinlang.org/
It mentions its capabilities, including KMP.

Suggested Solution

I propose we merge both things into one area: Kotlin
Redirect all kotlin-multiplatform docs to kotlin, and move all pages there.

The landing page can have the same clarification that we have specific Android and Java (JVM) docs, including Spring Boot, elsewhere.

A smaller banner could live on top of all pages that are specific to KMP, with this clarification about Android and JVM docs.

An alternative solution is to include KMP as a sub-platform. Similar to how Apple/iOS is layed out:

We could then have:

• Kotlin - Same as today, + an include to the same Kotlin Extensions docs we have under Java
• Kotlin - Multiplatform (contents of KMP docs today)

Some other ideas I'm not very convinced about:

• Android -> Just a landing page with a note to go to Android?
• All sub folders from Java?

Perhaps the docs infra could make Kotlin point to Java, but just change the icon/URL otherwise to be Kotlin?

@kahest @HazAT @buenaflor wdyt?

[kahest]

@bruno-garcia do you think having two items is confusing, or is the main point that it takes too much space? FWIW, KMP has much more traffic (2x that of Kotlin on the landing page), so I kinda like having KMP called out explicitly. No strong opinions against merging, but I wouldn't want to use sub-platforms/guides as we do for Apple, it's a bit annoying to maintain and only really usable if most of the content is the same IMO.

[bruno-garcia]

Yeah it was mainly odd to have 2 entries for what from the outside seems could be the same entry point.

Regarding the traffic I'd argue it's very likely the same traffic would exist under platforms/kotlin/multiplatform since the content would still exist, just the URL would change. We can redirect the existing URLs to the new path under /kotlin so links are not broken.
The current /kotlin doc not having traffic isn't surprising because it has no content so it'll be mostly people who land on the landing page and click on it to see what's inside. Only to find basically 3 links.

The part that makes it harder to justify changing things is:

I wouldn't want to use sub-platforms/guides as we do for Apple, it's a bit annoying to maintain and only really usable if most of the content is the same IMO.

If there's no easy way to structure things, then I don't know how we would do this.

Maybe @chargome or @coolguyzone have ideas?

[coolguyzone]

Hey @bruno-garcia, I like this idea, I think the number of SDKs we list is a bit overwhelming, anything we can do to consolidate it would be great. It seems reasonable to assume that people looking for Kotlin Multiplatform will click on Kotlin, it might cost them one extra click to get the content they want, but that seems fine to me. @lizokm may have thoughts about this as well.

[lizokm]

Would love to get @kahest and @buenaflor 's opinion as well :)

[kahest]

let's do it :)

[buenaflor]

no objections here 👍

[chargome]

Just want to mention that if you want Kotlin Multiplatform to appear in dropdowns etc. you will either need to keep it as a platform (like now) or as a sub-guide of Kotlin. Adding it as a guide will also open up the possibility of using a shared common folder, platform-includes etc. Otherwise it would be just a sub-page that has it's own content.

Adding it as a guide vs adding it as a sub page of kotlin will also impact search results as they are always scoped to guides or platforms (if applicable) – which should not be a big issue here I guess