Forum Replies Created
That’s not true, maybe in the .pot file you has, but it’s in the actual PHP files!
msgid "Search this website"
I rely not on .pot files but rather on scanning the actual framework files with each version — as these matter in the end what gets displayed and what not.
Also have look at this thread here for more discussion on this topic: http://www.studiopress.com/forums/topic/multi-lingual-translation-plugins/
Sorry for the late reply!
Yes the first mentioned plugin by you works like an “more comfort for the admin/ editor & user” plugin. It doesn’t add overhead that locks you in later but rather adds some additions to the admin workflow. And for the frontend it mostly adds the language switcher – similar to that from WPML.
A similar plugin compared to “Multilingual Press” is this one, “Multisite Language Switcher” which is a little more basic/simple but has a solid switch as well as some other basic settings on a per site basis: http://wordpress.org/extend/plugins/multisite-language-switcher/
WPML itself is a great concept and it works — but it adds lots of overhead and needs lots of additional plugins if you’re working with WooCommerce, EDD, BuddyPress and so. The internal workflow can also be complicated for editors because of the many additions on the edit screens. Also for more than 2 languages and lots of pages and/or posts it may lead out of order sometimes…
At first sight, Multisite may look like it’s “too much” for that task but if you already worked with multilingual sites then it’s the currently best option overall, especially when you just keep all with WordPress default stuff
What @Remkus said!
The search placeholder string definitely changed from “Search this website %s” in 1.8.x to “Search this website” in 1.9.x!
The search button string did not change as of my comparing — but if the language file for your language was not properly made then this still could lead to non-loaded/non-displayed translated strings.
Also, like @wpsmith said, if you have modified such strings via functions.php — like suggested by the tutorials regarding “Search” on StudioPress here, then this will be used instead of language file string.
To speed things up anyway, just jump in on the community translation portal mentioned above and @Remkus will add all these to the Genesis Translations plugin.
–David Decker, community translation helper
December 19, 2012 at 7:35 am in reply to: Debugging: How to know what page is being executed? #6141
Premise landing pages and WordPress pages with the “Landing Page” page template are 2 totally different things! The included page template in Prose is just a small alternative for small & simple landing pages. Otherwise, landing pages with Premise are full featured and are fully independent from your current theme! You can only use one or the other for a specific landing page. If you’re using Premise anyways I am wondering why you still want to use a page with that template?
These instructions might be regarding the old Prose 1.0 version which had such a file. In spring of this year updated version 1.5/ 1.5.1 of Prose was released which no longer features a “custom.css” file. Instead, it has a custom CSS section which you’ll find directly under Genesis Settings as a submenu. There you can add your custom rules or override existing rules (with added “!important”).
In the case of Prose, it is NEVER recommended to touch the downloaded files! With version 1.5 and higher Prose has the ability for automatic updates included. In case of an update you’ll lost all customizations. So only use the provided sub settings page and add your CSS and custom functions (there’s an extra field for that too there.
Hope that clarifies this a bit. Dave
I can only emphasize what Remkus said: for new projects using more than 1 language I will only setup Multisite installs. That’s the solution I recommend to all clients since spring of this year. WPML is a solution for not so “techie” users but it is likely to happen they complain in the long run and will find themselves locked in…
The “Multilingual Press” plugin is an option – I consider it some helper tool but in the end it’s not needed. Multisite on its own is the native best solution. Not only for scaling reasons.
Currently this is not possible with the current plugin version! The slug/rewrite rule is hard coded, so no chance.
It neets to be changed to a filter or maybe to settings option.
I hope the plugin authors will change this soon.
November 20, 2012 at 1:17 pm in reply to: New Sub Forum Suggestions: Internationalization/ Translations #917
I like the idea of not having about 50+ forums for child themes that share mostly an identical code base and differ mostly only in some CSS.
For me the Help Desk feels like “Priority Support” (I’ve also experience on other platforms) and I absolutely go with that!
If this forum here is about to grow, which it IS, we shortly have a big new “knowledge base” which also will contain child theme specific information.
The propagated use of tagging makes really sense because child themes not only consist of PHP & CSS but are part of OUR PROJECTS! Therefore we have to deal with different languages for example… If properly tagged we will have lots of aspects for a specific child theme on the table if needed
November 20, 2012 at 12:34 pm in reply to: New Sub Forum Suggestions: Internationalization/ Translations #906
Thanks for your feedback, both!
I agree with Nick, that it would be really cool to have some language specific discussions/tips/whatever in one’s native language
So, since Brian just opened a sub forum, we have our place to go: