automattic / babble Goto Github PK

Possibly generate these from the WP_LANG_DIR . "/$locale.php" files, e.g.

http://i18n.svn.wordpress.org/he_IL/trunk/dist/wp-content/languages/he_IL.php

I think the synced attributes will be:

• comment_status
• post_password
• post_parent (indirectly)
• menu_order
• post_mime_type?

Either wp-content/languages or wp-content/themes/[current theme]/[select dir] (or something).

Looks like we have an issue with the URL which comes back after you comment.

1
I'm looking at a French language translation of an English post (custom type). I submit a comment, and the screen refreshes. But it's a curious mix: the post content is French, but the chrome is English. (eg 'Home' in the tab bar, rather than 'Accueil') Looks like an issue with the URL that comes back:

/en/media_fr_fr/fr-a-muscular-view-of-free-speech/

2
I'm looking at a French translation of an ordinary 'post'. I add a comment, and the screen refreshes to:

/2011/12/09/experience-synchronisation-des-commentaires/#comment-27

... giving me a 404. But if I add the 'fr' manually to the front of the URL, it's fine.

Off the top of my head:

• is_front_page – e.g. should is_front_page return true on http://example.com/de/?
• is_home – similar issues to is_front_page
• is_page – can we make this return true for post_types shadowing the page post_type, e.g. page_de and similar?
• is_attachment
• is_category and is_tag – how does this cope when on the archive page for a taxonomy which is shadowing category, e.g. category_de and similar
• is_tax – similar problems to the is_tag
• is_page
• is_singular – if you use is_singular( 'post_type' ) what should happen when you're on a shadow of that post_type?

Thoughts?

New post screen:

• Notice: Undefined variable: post_id in babble\class-post-public.php on line 778

All screens:

• Notice: Undefined property: stdClass::$display_name in babble\class-switcher-menu.php on line 175

For example, in the admin area you shouldn't be able edit a German post when the admin area is set to Hebrew.

For example, in the front end, you should't be able to edit a French post when the URL is under the /en/ virtual language sub-directory.

I'm running my copy in a subdirectory of my web docroot:
http://macmini.local/fsd/

Babble adds the language code on the end, which should give:
http://macmini.local/fsd/en/

But instead, I'm losing the fsd part, and getting:
http://macmini.local/en/

Something to do with the home_url filter I think, causing AJAX loads to recurse infinitely. Or something.

Need to avoid adding shadow post_types for shadow post_types, lest the universe collapse in on itself.

It should return whatever the front page of the site is set to.

When editing German language content in the FSD site I came across this situation:

A parent and child post of post_type principle_de_de which have the same post_name and which wouldn't allow the post_name to be edited by changing the slug below the title in the admin edit UI. I changed the post_name in the DB, flushed the object cache, and it now seems fine.

One to keep an eye on.

As we currently set the transid term when a post is in auto-draft, we need to be sure that when we get posts in a transid for menus and such, we don't get auto-draft posts, draft posts, etc, etc.

We don't yet have comments being collated from all translations into a single thread.

Comments added to an English version are only then appearing on the English version. Comments on the French version appear only on the French version. And so on. Seems to affect all types of post: built-in posts, and CPTs.

You probably know that. But better to put it down here, just in case.

Just upgraded my local copy of WP trunk to the new WP 3.3 beta 1. The 'Add New' dropdown is listing 'Post' multiple times - corresponding, judging by the URLs, to the various translations of each post type.

https://skitch.com/simond/f951r/edit-post-wp-trunk-wordpress

Was this happening with previous versions of trunk? I don't remember seeing it.

Currently, when viewing the German Hello World, the permalink for the English Hello World is prefixed with de_DE. Not good.

Abstract the code currently in sil_admin_bar_menu so it can be used for a language switcher anywhere.

I'm running Babble in a child site of a WP multisite install, which itself is in a folder within my docroot:
http://macmini.local/wordpress/babble/

Themes calling home_url (eg all current Automattic themes) are coming out:
http://macmini.local/en/

Themes using bloginfo('url') seem to be coming out right... but I think there's an issue with double-slashing. Thematic and Carrington give:
http://macmini.local/wordpress/babble/en//

Currently there's an infinite redirect loop on the homepage.

Check the plugin works as expected in an “actual” subfolder install (i.e. where WordPress is installed in a subdirectory off the document root) and in a multisite subfolder install (i.e. a WP network setup to use subfolders rather than subdirectories).

It should show appropriate content for whatever the front page of the site is set to.

Same UI as for posts, and a similar approach.

Posts in a translation group should sync the dates as follows:

• post_date and post_date_gmt should treat the post in the default language as canonical, i.e. the date on the post in the default language should be sync'd to all the other posts in that translation group.
• post_modified and post_modified_gmt should be individual to each individual post, e.g. the German translation will have a different modified date from the default language post.

We need a proper way to assign default language: filter? constant? option? something else?

Currently our filter on home_url wreaks havoc with the RewriteBase and last RewriteRule.

Use a taxonomy instead of postmeta.

i.e. they shouldn't all be associated with the default language post types.

e.g. the taxonomy tag_de_de should be associated with the post_type post_de_de.

You might know this already; but the dropdown list of languages in the Admin Bar is only showing me German and Hebrew.

I've got German installed already in that install; and if I switch to German, I see German. That's great. But I don't have Hebrew. And the dropdown isn't listing the many other languages I do have installed.

Move all language detection, locale, etc, into class-locale.php.

Just activated the plugin, getting this message:

Warning: array_keys() expects parameter 1 to be array, null given in /Users/simond/checkouts/github/babble/babble-poc.php on line 54 Warning: array_merge(): Argument #2 is not an array in /Users/simond/checkouts/github/babble/babble-poc.php on line 54

I'm running it in a completely fresh child site in my main multisite install.

(e.g. a GET param on the front end, like ?lang=en)

When filtering a post list in the admin area by a term, the get_transid throws the exception show at the end of this issue.

To reproduce:

1. Install Babble, etc
2. Create some posts and categorise them
3. Go to Admin > Posts > All Posts and click on one of the categories or tags shown in the table list
4. Boom

The fatal error with back trace:

[26-Jan-2012 11:58:30] PHP Fatal error: Uncaught exception 'Exception' with message 'Please specify a target term_id' in /srv/www/freespeechdebate.com/htdocs/wp-content/plugins/babble/class-taxonomy.php:776 Stack trace: #0 /srv/www/freespeechdebate.com/htdocs/wp-content/plugins/babble/class-taxonomy.php(603): Babble_Taxonomies->get_transid(NULL) #1 /srv/www/freespeechdebate.com/htdocs/wp-content/plugins/babble/api.php(94): Babble_Taxonomies->get_term_translations(NULL, NULL) #2 /srv/www/freespeechdebate.com/htdocs/wp-content/plugins/babble/class-switcher-menu.php(100): bbl_get_term_translations(NULL, NULL) #3 /srv/www/freespeechdebate.com/htdocs/wp-content/plugins/babble/class-switcher-menu.php(51): Babble_Switcher_Menu->populate_links() #4 /srv/www/freespeechdebate.com/htdocs/wp-content/plugins/babble/api.php(495): Babble_Switcher_Menu->get_switcher_links('bbl-admin-bar') #5 /srv/www/freespeechdebate.com/htdocs/wp-content/plugins/babble/class-admin-bar.php(23): bbl_get_switcher_links('bbl-admin-bar') #6 [internal function]: Babble_Admin_bar->admin in /srv/www/freespeechdebate.com/htdocs/wp-content/plugins/babble/class-taxonomy.php on line 776

e.g. de vs de_DE

Check that uploaded images can use all built-in and custom image sizes (e.g. sizes added with add_image_size) in the theme. There is a suspicion that under some circumstances the ‘physical’ image files are created, but the metadata pointing to them is lost and so the files linked on the page in the image src attribute is the full size image.