aia

Thanks! How about automated conversion?"

What will happen to statuses once they are deprecated? Will the content just be lost, or will we be able to convert it to another form (like topics)?

Yes, +1. Not only support for embedding uploaded AVIF files but also for converting outdated formats (JPEG, GIF, WebP, PNG, HEIC) to AVIF upon uploading would be amazing!

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.