this is a featured image test.
I tried to reply with my latest feedback on WordPress.org handling of Translations but sadly my comment was not approved. I’ve tried to have conversations with developers on WordPress’s slack system but instead of considering the problems I raised I quickly got responsive answers.
Here’s my reply so hopefully someone will read it who develops for wordpress.org and will possibly consider some of the ideas I have for fixing the complicated mess that exists today with plugin (and theme) translations on WordPress.org.
A reply to thread Hello Polyglots, First I would like to say
First I want to make this clear, though I am very critical (I am by nature, i am a developer), I support the translation efforts. I know the reaction when someone criticizes the way things are done is perceived as anti WordPress, that is not the case with me. I will call out BS, but again I’m a developer it is in my DNA. I can tell you as a project supervisor, the way this is setup currently will never scale to the 40,000+ plugins, let alone the themes.
I am glad to see for once a thread not get deleted and actually being replied to that points out some of the problems with the way things are working now. Is there now an official way how we can post these issues or is it hit or miss if they get deleted or replied to? I’ve tried to discuss them on here (they get deleted), also on slack I was given answers (that technically did not answer my concerns) rather than have someone listen to my concerns and let me know my concerns would be considered for discussion (responsive vs considerate support).
These are my thoughts as a plugin developer who is not on the WordPress.org core team. Please take my thoughts and ideas into consideration. I think ideas and critical thought from outside WordPress core is necessary from time to time, like any project or application.
* Plugin developers should be trusted with their translations. This would solve a lot of problems. Yes there will be plugin developers who just use Babelfish or Google Translate, but I have an answer for that at the bottom of this reply.Note: It is common for a company to pay someone to do translation work. In this example, even though I do not speak French, I may have the translations for French that my company paid for to put into my plugin. The current procedure prevents me from doing this translation when I ask for such access simply because the polyglots moderator says I do not speak French. (who owns the plugin and its’ translations?)* Let plugin developers determine if a translation can happen or not regardless of percentage completed. I know if the developer doesn’t speak that locale language the translations may not be “correct”, but that is how it works today when not using translate.wordpress.org. After all we want to provide some translation rather than none. None is way worse than 50% translated.* Provide a simple way for plugin developers to add/remove WordPress.org users as translator editors. It should be in the same place we add additional committers to our projects. Then the current method of posting a comment in a particularly specific way can end which is very frustrating. The latest example how to post requesting translators I saw wants you to praise the team in your introduction, this seems rather self-serving to me, almost as if to reinforce the system in place now is a good one.* Translate editors should be strict. Meaning if I don’t add translator editors to my project, no one I don’t know is approving translations for my plugin without my knowledge. Yes I know the idea is to allow global translation editors can approve translations for whatever plugin, but this brings up legal issues (see my GPL comment below). Perfect world, the plugin author could simply check a box to say “my translator editors only” or “global translators allowed” next to each locale.REST OF MY ITEMS ARE ADVANCED ISSUES*Let plugin developers decide if a translation can even happen. There are situations where I may not want anyone to create a translation into a particular locale. For example, lets say we were going to launch a service in England in April, we may not want a version allowed to be translated until that release.* Let the plugin developer have the ultimate say about translations. I may have my companies lawyer tell me the translation of a word we use as a trademark in the US cannot be used in France. That that point I as the plugin author need to be able to change that translation (not the translator editor I picked) Ocean90 pointed out some code I can add in PHP to do this but it did not quite answer this specific case, only how i can target locales.* Ultimately, the translation is part of the plugin and thus the management should be in the control of the plugin developer. Not allowing the plugin developer to have this control means that derived works are technically branches or forks owned by someone else (other than the plugin developer). This brings up legal questions, is a translation where the plugin developer cannot modify or control the translation still part of the original plugin or is it a derived work (where other parts regarding trademarks and copyright need to be modified). With everything falling under GPL here at WordPress.org, it would mean that the inaccessible by the plugin developer translated plugin technically should use a different name and modify the copyright, and give credit to the original plugin developer to make sure not to imply the derived work was his/hers. This problem is solved simply by allowing plugin developers complete control of who can and cannot translate their plugin including themselves (see my first item above).I believe the scale-able solution is to allow Global Translation Editors the ability to grade translations that have been approved by non global translator editors. This would be viewed as some sort of star rating or grade percentage next to the translation that then the user can decide if it is good or not. That would solve the issue about quality of the translators in a community driven organic way. Also solves the problem if only 90% of the translation is completed, automatically the grade would be at most 90%.This is what I would like to have access to as a plugin developer. A place in the plugin’s admin page that would list all of the locales in a table form with options:locale | translator editors | translation allowed by | translation grade | actionsen-us | user1 x, user2 x, … | () global translators () plugin translator editors () plugin author only | 85% of translations accepted by global editors | add translator editor| – separates columns in table() – radio button (defaults to global translators)x – next to user name to remove translator editorI’ve already had folks reply telling me this cannot be done for random reasons. I beg of the team to instead respond with reasons why it cannot be done, please consider discussing these ideas first.
Plugins and themes have translators we trust 100%, we’ve forged relationships with these translators over the years. I’m now finding myself telling my friends and colleagues “I trust you, but for some reason WordPress doesn’t trust me with my plugin”. This all stems from the confusing process that is in place now which can be easily fixed giving the plugin and theme owner direct control of their translators.
UPDATE: After speaking with team members on slack about the process, I’ve now learned that the terms used for translation have changed. These new terms are used by the polyglots team but have not been updated on the documentation, hence the confusion. First some terms to clear up…
Translator Editors != Translators – The plan is to let anyone be translators, but only editors could moderate and approve translations.
Translators != Validators – Same as above, translators can make translation recommendations, only validators can also make translations and approve translations.
new latest process WordPress.org has in place to manage translations for themes and plugins is two fold. First there are “Translation Recommendations”, then there is “Translation Recommendations with Validations”.
If a plugin or theme owner would like users to “recommend translations”, all the user has to do is create an account on wordpress.org. Anyone with an account on WordPress.org has permission to “recommend” translations for WordPress core, as well as any theme or plugin. I am sure this will not last long, once malicious users get their hands on this the WP.org team will be forced to chance this policy. I like the spirit of this though, but they do not make this clear in the documentation. The way it is written currently and the terms used “translator” and “translator editor” implied to me that once the user created an account they still had to be added as a “translator editor”, but that is why they’ve changed the terms.
Translation Recommendations are placed in a queue to be confirmed or marked fuzzy by translation moderators (Translation Editors or Validators). Plugin and theme developers can request specific users to be validators for specific locales.
Translation Recommendations with Validations
If a theme or plugin owner wants specific users to “translate and validate” translations in particular locales, a request must be made in this comment thread (must include the word “request” in the tag field otherwise your requests go into a black hole) and request users to be “validators” for specific locales for your plugin/theme. Specifically you need to include the following in your posting:
locale code (en or en_US) – @WP.org-User-Name – slug name of your plugin
As of current, plugin/theme owners can only request validator users and must wait for the users to be approved. There is no simple add option like that for adding committers to your project. It appears they are approving all requests, but the process is taking very long to do so. As I understand it, they are not rejecting requests, plugin and theme owners can rest assured they have control of their translations if they request it.
How Translation should be for themes and plugins
Plugin and theme owners should have control who can translate their plugin/theme, which languages can be translated, and be able to add remove translators. Plugin and theme owners should be able to add themselves as validators for any or all locales as well.
Plugin and theme owners should have the ability to decide if a translator has “full translation control” (translator and validator) or if their translations should be moderated by someone else (other valdiators). I like the idea of anyone making translation recommendations, but there should be management screen with setting in a grid view where we as plugin/theme owners can decide if locale can or cannot be translated as well as enable/disable if translation recommendations are from anyone, or allow fur adding specific users. A grid where the columns are “locale”, “enable/disable (enabled by default”, “Allow anyone to recommend translations”, “recommend translators”, and “translation validators”. Each row would have the locale. The cells within the “recommend translators” and “translation validators” would have a textbox with an add button to add validators, as well as list the current validators with a button to remove them.
These proposed options above would allow a theme or plugin owner to add someone as a translator exclusively, they will not have to be distracted by anyone on WordPress.org making recommendations. The plugin author can also decide if a particular locale should be available or not for their plugin. Defaults though should follow what WordPress.org has in place now which encourages anyone to contribute.
The idea that plugin and theme developers cannot control the process, and that translations happen without the interaction of the theme/plugin developer in my mind violates GPL and certainly creates issues for copyrights. Luckily, this is not the case. Currently the polyglots team is changing “terms” for translation management which lies the confusion.
Why do Theme and Plugin Developers need to be moderators of their translations?
As creators of a product, albeit free and open source, there are situations where words, phrases cannot or should not be translated. For example, a website name (not the URL), plugin author should be able to decide if it remains as-is in some languages but can be translated in others. Many of these terms are copyrighted and in other cases, are technology terms that if translated, may cause more confusion. It should be up to the plugin/theme owner to have final say.
There is a way in the code to prevent some parts of strings to not be translated, but it does not control this down to the specific locales.
Another problem comes with companies who have translators on staff and can do translations. Our company has to add our employees (which can change over time) to have access to translate. What was a simple here’s the po file go to work operation has now turned into “I have to wait for WordPress.org to approve our our employee fluent in French to be a validator for our plugin”.
Plugin and theme authors should be able to decide which languages are translated. Though I wouldn’t use such a feature, I could see a company like Facebook prevent translations for certain languages/locales until they have the language locale added to their service.
Current process does not scale
The current process at translate.wordpress.org is not going to scale to 40,000 plugins with 50+ translation possibilities each. I don’t care how many volunteers there may be helping with translations, adding a comment to a blog post it’s not going to work, we’ll see some plugins receive priority moderation (validating) over others, which will more than likely be influenced politically.
At some point a page for plugin owners wil lneed to be created that lets them pick a locale and enter a wp.org user and click ‘Add’. The faster and smoother they can make this process the less confusing it will be for all involved, and the faster new translators will start contributing.
I’m already wasted a few weeks trying to figure out how the process works, which appears is still being figured out, which also bothers me that these problems were not even discussed or thought about.
I want centralized translation to work
Do not read above and believe that I am anti WordPress or anti translation. I want this to work. To not trust the plugin / theme authors with the responsibility of controlling their translations is not only wrong, it poses the problems I describe above. This process needs to be fixed ASAP.
I would ask that you do not post comments here. Instead, I’ve opened a trac ticket requesting that this process be changed. Please comment there so WordPress translate team can read your concerns about how theme and plugin translations are currently managed. Update: My Trac ticket has been closed, feel free to comment below.
You can now read ID3 (media file headers) information from mp3 and other media files using GetID3 library without having the entire media file present. The new 2nd parameter to the analyze() member function allows you to detect play time duration with only a small portion of the file present.
Years ago I added this code to the versions of the getid3 library we packaged with the Blubrry PowerPress podcasting plugin. I’ve submitted this code to the getid3 project so everyone can benefit. As of GetID3 v1.9.10, you can now pass a second optional parameter specifying the total file size. This parameter sets the file size value in the getid3 object, skipping the need for the library call the filesize() function.
This is the secret sauce that allows PowerPress to detect the file size and duration information from a media URL of any size in only a few seconds.
The new parameter only works if the following are true:
- Have enough of the beginning of the media file that includes all of the ID3 header information. For a typical mp3 the first 1MB should suffice, though if there is a large image within your ID3 tags then you may need more than 1MB.
- Have the total file size in bytes.
- The mp3 file is using a constant bit rate. This must be true for podcasting, and highly recommended if the media is to be played within web browsers. Please read this page for details regarding VBR and podcasting.
// First 1MB of episode-1.mp3 that is 32,540,576 bytes // (approximately 32MB) $media_first1mb = '/tmp/episode-1-partial.mp3 $media_file_size = 32540576; $getID3 = new getID3; $FileInfo = $getID3->analyze( $media_first1mb, $media_file_size );
You can use a HTTP/1.1 byte range request to download the first 1MB of a media file, as well as a HTTP HEAD request to get the complete file length (file byte size).
Byte range requests and HEAD requests are safe to use for podcasting. If a service does not allow HEAD requests or accepts byte range requests, then they will have bigger issues to deal with as these features are required by iTunes.
Blubrry PowerPress podcasting plugin has been using this logic to detect mp3 (audio/mpeg), m4a (audio/x-m4a), mp4 (video/mp4), m4v (video/x-m4v), oga (audio/ogg) media since 2008.
Not all media formats support this option. You should test any format not mentioned above. For example, ogg Vorbis audio works, ogg Speex audio does not.
Ty passed away today. His kidneys failed, it all happened rather quickly.
We miss you buddy!
If you’re not aware, last Summer (August 15th I believe) Amazon.com removed the “User Contributed Images” feature. If you’re like me and uploaded additional product images and wanted to find them for reference, you’re going to be searching for a very long time.
To find your uploaded images, go to amazon.com, sign-in, then navigate to your profile. (or try this link: https://www.amazon.com/gp/pdp/profile/) Once you are viewing your profile, click the “images” tab just below the “Contributions” heading. When viewing with Google Chrome the larger size images do not load. Firefox seems to not have an issue.
What is available:
- Tiny thumbnail image
- Title / Caption
- In-image notes
I think this is a real bummer as many of my product reviews reference the images. I’m now in the process of writing blog posts of these product reviews with the images.
I’ve moved the monthly updates on Project Trans Am to my Mods and Rods.tv blog and podcast.
My latest post covering everything I’ve done last August with photos is available here: http://www.modsandrods.tv/2013/04/04/project-trans-am-for-march-2013-insulation-completed-focusing-on-the-interior-and-wiring/
Outline of Accomplishments LAST MONTH
- Insulation Completed
- Carpet Installed
- Kick Panels, 1/4 Panels and Sill Plates installed
- Oil Pressure and Water Temperature Lines Installed
- Added a 4 Blade Fuse Block in Glove Box
- T-top Headliner Cut and Glued
Car is finally coming together! I should have the interior back together this April. If I can stay on schedule hopefully Fathers day weekend the Trans Am will be back on the road!
Somehow I’ve had some time to do some home improvements over the past couple of months, mostly the past few weeks.
Pressure Washed and Painted the Fence
With the neighbors help, I got the fence painted! Nothing special, we used the same Cabot Cedar stain as before. The first coat lasted 4 years, though it could have used a coat a year ago. Pressure washing showed a lot of black staining over the years, and I repaired one broken picket, otherwise the fence looked great.
Lamp Post Replaced with Solar LED Post Light
I’ve been thinking about repairing the leaning post and replace the natural gas lamp light with a solar powered one. Last weekend the weather was finally warm enough for me to investigate. After digging around the post about 3-4″ deep, the post fell over. Quick examination I found the post completely rusted through. Fixing the lamp post turned into a replacing the lamp post project. I proceeded to dig out the hole beyond the frost line, about 34 inches deep.
I thought I could find a simple replacement lamp post at Lowes/Home Depot, but guess again, they sell more complicated posts that are way over priced. Since I don’t need a fancy post with an extra electrical socket built-in, I found a simple and affordable post at Menards, though it required a trip across town. When I got back, I just had enough time to pickup 2 bags of concrete, mix and then set the post before nightfall.
While I was disconnecting the gas line to the lamp post I went ahead and removed the line to the gas meter and capped it with a 1/4″ NPT cap.
The following Wednesday the solar powered lamp I ordered arrived. It only took 5 minutes to install. Compare that to the entire day it took to replace the post! We had to wait another day to see if it would charge and light up. Thursday night it came on when the sun fell. As expected, it put out a comparable amount of light to that of a gas lamp. Three hours later the battery died. Luckily you can add a 2nd battery pack to extend the battery life. I knew the light from an LED solar powered lamp would not be as bright as a electric light bulb, but it is as effective as the gas lamp it replaced. If it could just last a little longer into the night then we’ll be all set. Most important though the yard looks good again!
Front Door Sealed
In October I decided it was time to do something about the draft under the front door. I first replaced the bottom gasket with a one size fits all 4 blade model at Home Depot. I quickly discovered the bottom seal of the door was not designed for the gasket I had purchased. After a few days of the family struggling to open/close the door, I decided to modify the gasket by removing the first 2 blades with a utility knife. It did the trick, but it also allowed a slight draft at the corners of the door. The draft was due to the door sill plate having a slight pitch running outside (rather than flat or to the inside). This pitch is also why the newer gasket was so hard to open/close the door.
This past weekend I decided to fix the entire problem by replacing the bottom sill plate. It was not as easy a task as I thought it would be since the original door sill plate was attached to the door frame, rather than the sill plate attached to the bottom house framing. Once it was removed, it was just a slow process fitting the replacement sill plate in place. I put a small bead of silicone between the sill plate and the house framing to insulate between the two joints. I also had to add about 1/4″ of spacers to the assembly of the sill plate so the top of the sill was tight against a new 4 blade door gasket. It did the job, the door is now easy to open and close and it’s air tight!
Future Home Projects
There are a lot of things we’d like to do with the house, such as finish part of the basement, redo the master bathroom, upgrade the bathroom fixtures throughout the house, and install a wood laminate flooring on the first floor. Perhaps 2013 I’ll have something more exciting to blog about as far as home improvements are concerned.
I’ve moved the monthly updates on Project Trans Am to my Mods and Rods.tv blog and podcast.
My latest post covering everything I’ve done last August with photos is available here: http://www.modsandrods.tv/2012/11/05/project-trans-am-month-30-interior-and-wiring/
Outline of Accomplishments
- New Windshield Installed
- Interior hard plastics and metal restored (except headliner, seats and carpet)
- Carpet and headliner material ordered
- Inner fenders painted
- Wiring problems assessed and added 4 relays to power windows with my own changes
Plans for November
- Remove rust from floors, paint, and seal seams
- Install sound deadener and insulation in passenger compartment
- Install carpet, dashboard steering column and center console
- Slowly install remaining interior while working on the motor
Hopefully I can get the interior far enough that all the necessary gauges and wiring is hooked up so I can focus on finishing and installing the new motor.
My Trans Am resto-mod project is finally coming together!
October is ending up as the interior and wiring month for the project, something I’m more comfortable working on frankly. The interior parts have been refurbished with fresh coats of interior paint applied. The electrical wiring is being evaluated currently, the plan is to reuse the existing harnesses as much as possible and only repair as necessary. Check out some pics of the freshly restored interior.
Hopefully over the next 2 weekends I will have all the wiring fixed, dash installed and sound deadener/insulation with carpet installed, which will allow me to think about installing the engine this November!
Check out the work I did last month on ModAandRods.tv blog: http://www.modsandrods.tv/2012/10/02/project-trans-am-month-29-brakes-and-ac-delete