aia

Ability to Set Language in the URL For optimal SEO and multilingual support, it's important to allow setting the language in the URL. Instead of having multiple languages in a single URL like invisioncommunity.com/forums/, we should have separate URLs for each language, such as: invisioncommunity.com/en/forums/, invisioncommunity.com/es/forums/, etc. This approach helps search engines accurately identify content in specific languages, leading to improved rankings for those languages. Link Tags for Specific Languages When different languages are presented on separate URLs, we can also inform search engines and browsers where other language versions can be found: <link rel="alternate" hreflang="en" href="https://invisioncommunity.com/en/forums/" /> <link rel="alternate" hreflang="es" href="https://invisioncommunity.com/es/forums/" /> <link rel="alternate" hreflang="x-default" href="https://invisioncommunity.com/en/forums/" /> Making Every Title, Item, Comment, and Other User Input Fields Translatable Only a small portion of posts typically drive traffic to any website or community, and many authors of these posts (topics) would be willing to translate them into multiple languages if given the option. While most users may not translate their less important messages manually, automated translation can handle this task well, especially with the advancement of LLMs in translation tasks today.

Does it allow restricting only external images without affecting other external embeds? If not, I hope this improvement will be made ASAP.

For my case, I only need a flag indicating 'Used in Frontend'. To accommodate all scenarios, you can consider marking strings with one or both of the following flags: 'Used In Frontend' and 'Used in ACP'. This allows flexibility depending on where the string is used.

In the language translation interface, we need a filter for language strings used in the frontend. This would be super useful for frontend translations on multilingual websites where we don't need localized ACP but have readers from different countries. It would also be great to have this information in exported XML so that it is available for external translation tools.

Can we disable image embedding (currently known as 'Insert image from URL') from third-party domains using this feature? As part of the solution to this problem.

As I recall, it was proxying, not uploading, so it wasn't as reliable as uploading and quite overengineered. Immediate one-time uploading from third-party URLs is much simpler and much more robust than proxying them all the time.

Several years ago, there was a discussion suggesting the enforcement of uploading images rather than embedding them from third-party URLs. It's a very important feature because images hosted on third-party URLs often become unavailable, making many topics immediately less useful. With this feature, every time a user pastes a URL to an image hosted on an external website, it should be uploaded and embedded as an attachment, rather than relying on unreliable third-party URLs. However, it appears this feature has not yet been implemented. So, I hope this will be implemented in the future.

Is it on the roadmap? We also need support for fully-multilingual content (titles, content items, etc.). We requested this a long time ago in the previous decade, but there have been no significant improvements in internationalization/localization since then, which is super sad for multilingual community owners 🥲 If IPS have any plans to improve internationalization/localization features, please let me know. I can provide highly detailed information on what is needed in our case.

And filer/search. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist https://www.w3schools.com/howto/howto_js_filter_lists.asp * Ideally, this approach should be used everywhere in long lists of options, not just in the stock replies list, because currently navigating long lists in IC is a nightmare.

This simple feature will greatly decrease confusion in cases where messages are moved to another topic. Currently, it appears as if they have disappeared, which leads to a poor user experience.

Because the filter (on the left) has inconvenient and unexpected default settings. Ideally, it should display information for all possible sections by default, rather than filtering by the first item in the filter list. Scroll down a couple of miles and you will see the "Forums > Posts" filter, which is suitable for your case and will show the desired reactions.

Yes, FURLs are the way. I'd prefer to have FURLs for everything that should be indexable by search engines, and just a simple rule in robots.txt that disallows indexing of anything with additional (non-FURL) parameters instead of a bunch of disallowed parameters.

Can we please have more details on how content will be changed (rebuilt) with the v5 upgrade? We already know that spoilers will be updated (and rebuilt?) from divs to details+summary, which is good. However, the main concern is inline styles, especially those involving text and/or background color. Throughout the lifetime of v4, forums have accumulated many messages that were copied and pasted into the editor, with colors not being removed. Consequently, many messages in v4 contain inline styles that are not visible to users now but will become apparent when we finally get dark mode. For example, this message was copied (CTRL+C, then CTRL+V) from here, and this is how it will look in dark mode: So, the question is, will the content rebuilding task include an option to remove these styles in order to fix this side effect of insufficient style clearing in v4? Also, more information about content rebuilding plans might help identify potential issues, so we would be grateful if you could share them sooner rather than later. Thank you.

I'm ready.

Hardcoded widgets are painful to move to desired positions. Please make them movable, just like other widgets. For example, the statistics in the topic (which eats a whole column in the topic view by default).

@Matt Finger, again, we're talking only about one region below the entire content (not "every block"), so everything you've mentioned is not relevant to the suggestion. The implementation of the interactive area exactly as it was described in the suggestion will only improve UX and won't affect anything else in any way.

Exactly the same as already implemented. My suggestion is for improvement, not replacement. The main idea of the interactive area is to prevent people from getting stuck in a state where they are unable to add a new paragraph at all (which happens quite often in CKE now) or are forced to look for unintuitive buttons on other elements (as implemented in IC5). When they can start typing into a paragraph with just one click in the same intuitive zone, regardless of the contents, they are no longer stuck. They can move blocks wherever they want after adding new paragraphs, etc.

Yup, a must-have feature. I implemented it myself in the current CKE, and I hope IC5 will allow doing it too. Or, even better, it will finally include it for all IC5 users

It seems you misinterpreted my suggestion. You 'don't agree' with something weird that you came up with yourself because I never said to do that. I would not agree with that either I only suggested adding one interactive area, which allows typing in the paragraph only upon interaction, and nothing like what you described. In this implementation, it does not have any of the drawbacks you imagined.

Those elements are not intuitive for inexperienced users (i.e., almost all users). It would be much more intuitive and easy to use if there were an area where users could click to start writing in a new empty paragraph. This area should always be placed right after the existing content in the editor: If this is implemented, even inexperienced users won't get stuck in a state where they can't add a new line and don't know where to search for a button to do that.

It's worth remembering that its behavior could be adjusted for specific regions such as Pages, while global defaults could follow best practices.

It's important not only for SEO but also for accessibility, especially for screen reader users. The usage of more than one H1 tag is considered a bad practice for a reason, as highlighted even in MDN docs. By the way, Google isn't the only search engine in the world. I know it's (almost) not the case in the US, but other countries also exist on this planet.

H1 must be removed from this menu. Also, its insertion should not be triggered by just one "#" symbol (Markdown). Each page must have a unique H1.

At present, shorts are embedded using a 16:9 aspect ratio, which is not ideal since their actual format is 9:16. It would be nice to fix this. Adjusting the embed settings to match the native 9:16 aspect ratio of shorts will enhance the viewing experience and maintain content integrity. Now: Should be:

Transitioning from "Display Name or Email" to solely "Email" logins isn't seamless for users who have stored their login credentials using their Display Name. They repeatedly click "Sign In" without comprehending the issue when login attempts fail. Adding a simple tooltip to the login field when the entered value is not an email would greatly improve UX in this case. This way, users can easily see and switch without encountering further problems. Example: Also, it would be a good idea to keep the "Sign in" button in this form dusabled until both fields are valid (email is validated and password is not empty), so users won't waste their login attempts with this kind of little mistake.