Hi Chouby, Hi Joachim!
The development of Polylang is really impressive! In my production website (WP v.3.3.1), I still use the 0.7 version, as 0.7.1 didn’t work.
I have activated a very useful plugin – Content Aware Sidebars – it enables to create sidebars for specific pages/posts, which will replace or be merged with the standard sidebars (primary, secondary, 4 footer sidebars).
The problem is, the Sidebars are a type of Post, which makes Language choice to show up in Sidebar Edit screen. But Polylang enables assigning languages to the Widgets already.
When I have ignored the language (left default) for all Sidebars, and added widgets for all 3 languages, every page in my default language was showing all the sidebar widgets in this language.
A workaround is to set a different language (unused in the website) for the Sidebars. I’m not sure, whether Content Aware Sidebars or Polylang could be modified to improve the compatibility, but I hope these infos could be useful for you.
Edit – WP version, link to C.A.S. plugin
If I understand well, it would be better that the content aware sidebar posts are not filtered by language.
What was wrong with Polylang 0.7.1 ? My intention was to correct bug, not add new ones…
Sorry, that I haven’t written it before. I have made backups, and updated the plugin via dashboard – I got some error about error handling in line 300 or something – I have forgotten to make a screenshot, I needed to quickly add new content, so I had to revert immediately…
I think the problem here lies in assigning the language twice: once to a Sidebar, which is designed as a custom type of post, and second time – in the standard way, in each widget.
I suppose, that it is enough, if only the language metadata criterion is fulfilled (no matter if the proper post/page match is fulfilled), which is causing all Polish sidebars show up at each page in Polish language.
So it probably can be solved
- either if Custom Aware Sidebars shows Siedbars exclusively based on the criteria chosen in the plugin Settings (e.g. by category, or by literally specified/marked pages or posts)
- or if an option “display for all languages” could be brought back
- or if you could exclude some content (post) types from language classification
Oh, I hope you’ll forgive me – shame on me, that I didn’t contribute to the Polish translation, but my first localisation attempt was a bit too careless and caused me more problems than it solved… – in case of the Brunelleschi scheme, which I have localised for myself, it resulted in breaking the settings management, as the settings are saved in the language of the WordPress installation (or maybe…? no, I don’t want to say a bad word about Polylang ;P). Thanks God, you’re a more structured developer, than I am of a tester…
When I prepare myself this week, I hope to update to 0.7.2 this week.
Currently Polylang filters all custom post types and taxonomies which have show_ui set to true. Obviously, it may not be optimal for everyone.
I will not change that in the future, but I will add two filters in the 0.8 to allow programmers to modify the list of custom post types & taxonomies to filter by language. Thus people will not be stucked with filters they don’t want 🙂
Thanks for the feedback. Except the support of custom post types and taxonomies, I haven’t really done anything to support other plugins yet, but of course the support should be as broad as possible.
I haven’t really looked into your plugin, but I will need a translation plugin soon, so I’ll keep Polylang in mind. The filters sound as a good idea, but is there a reason why you’ve picked
show_uiand eg. not
public_queryableto determine which post types to include? The post type of Content Aware Sidebars is not public, because one shouldn’t be able to view these “posts” in the frontend.
If I well understood, the
show_uioption determines if there is an admin panel automatically generated for the post type and the user needs an admin panel to set the language (if no language is set, the post will never be displayed once the Polylang is activated).
I believe it’s convenient for users with use post types in a simple way. Of course, it may not be optimal for advanced usage. That’s the reason why I believe the filter is the best thing to do.
- The topic ‘Polylang Content Aware Sidebars issue’ is closed to new replies.