Forum Replies Created
-
Posts
-
for almost all use cases
By not forcing the user to set a particular language or, in other words, by allowing to set the (custom) post to be language neutral, it would become the basic common ground of <i>all<i> use cases I think, including the direction I am suggesting 😉
Why are you just looking to cover the most basic common ground; the ‘Post Language’?
What do you think about being able to set the language for things like custom fields, taxonomies/terms, options, …?
Alex, I feel the ‘Post Language’ feature is only suited for a limited number of use cases. It would be enough for a multilingual blog but not for a CMS with more complex post types. As said I would like to see a more flexible solution as explained in my initial comment above that would suite more complex cases like the described ecommerce/product one which has content parts that are language independent like e.g. the brand name taxonomy, weight, price, images,etc (custom fields), some options while other content parts are language dependent and require translation.
My suggested solution direction would allow your ‘Post Language’ feature, but would also take things (when desired) a step further by also making things like options, custom fields etc (optionally) language specific. All in such a way that it even would work when not planned for by the original (theme/plugin) developer.
+1 for suggestion of bobbingwide
Currently the people who never upgrade set the benchmark for the minimal required PHP version. I find that somewhat odd 😉
Wouldn’t it make more sense to set the minimal required PHP level based on the PHP version used by people who do care about keeping their sites secure and thus up to date?
For that it would be interesting to see at https://wordpress.org/about/stats/ which WordPress version is used by the people still on PHP version 5.2. I guess most of them are not on WP 4.0?
Also, I think if a PHP version is EOL, i.e. when it no longer will get security fixes, that WP should follow. Those EOL (end of support life) dates are known years ahead so e.g. when WP 4.1 comes out it could warn PHP 5.2 users that starting with WP 4.x that PHP 5.2 will no longer be supported. Maybe with a link to WordPress.org page explaining the why and the how. E.g. a lot of hosting control panels have a simple selector where you can switch the PHP version your self!.
I would like WordPress to be natively be multilingual, with preferably these abilities:
1. neglectable (performance/storage) impact for non-multilingual sites
2. makes any plugin or theme – out of the box – multilingual ready as long as it adheres to current (WP 4.0) best practices regarding i18n.
3. can group posts as language alternatives (needed to quickly find post translations)
4. if no language is specified on a table row it applies to any language
5. back-end can be single-language while front-end is multilingual.
6. regardless of the language set for the back-end, the user can switch the edit-language to any of the supported front-end languages.
7. slugs are unique per language
8. promote as best practise: put admin (back-end) specific translations in separate translation files
The sought after solution would allow the developer for example to define an option, custom field or term to be language specific (default) or not.
Even if a theme or plugin wouldn’t be built to be multilingual ready it would still be.
The editing user would simply set the edit language (in admin bar) to the required language and WordPress would automatically retrieve/save the correct data based on the current editing language and the defined language specificness.Of course all relevant API functions and hooks would need to incorporate the language into their logic too. For example, this way when a non-multilingual prepared plugin retrieves an option value it would get a language specific value!
Many theme and plugin developers who only used to and familiar with single language sites don’t understand the need for and problems and needs of multilingual sites. This probably won’t change for the majority of them. They don’t want to put the extra effort in to finding out what’s needed and how to implement it. The ones that do are put off by the lack of a standard. With the above proposed solution they wouldn’t even have to! It would work out of the box!
—
Most other suggested solutions come down to the idea that translation is always on a post by post basis. This it to limiting. E.g. in an e-commerce system a product has a lot of attributes that may or may not be language specific, options may or may not be language specific, taxonomy terms may or may not be language specific. So in this case we don’t want the store owner to type over the same data in every language they support when this isn’t (shouldn’t) absolutely necessary.
The extra problem we had in the past with multisite based multilingual solutions is that, besides the above, a lot of third party plugins/themes don’t play well with multisite.
