Welcome to the official blog of the TV review team for WordPress.tv
We approve and publish all videos on WordPress.tv as well as help WordCamps with video post-production and captioning and subtitling of published videos.
We use this P2 to post our progress, status reports, and occasional geeky video debates. Use the “Subscribe to Blog via Email” widget to follow along!
Want to help us?
Video Editing — You can see what videos we have that need editing in this spreadsheet. No special credentials are needed, just download the raw video file, and use your favorite app to edit.
Subtitles/captions — You can help us extend the reach of of WordPress.tv by adding captions or subtitles to any published video. Just find your favorite video, and follow the steps here to create a caption/translation file and submit for review.
Weekly meetings
We use Slack for real-time communication. As contributors live all over the world, there are discussions happening at all hours of the day. We have weekly team meetings every Thursday at 17:00 UTC, and they are open to the public!
It started with a very simple question in the Slack Channel:
As it was me – both moderating on wordpress.tv, as well being once the leadorganizer of WordCamp Nuremberg and the WordPress Meetup Nürnberg … wait, wait … we are already in the middle of the confusion …
A short step back in history: when 2016 the first WordCamp in Nürnberg was announced during the application and approval process also the website and the url for the subdomain was setup. After a short confusion of getting to ” … burg” nuremberg.wordcamp.org was established. At that time a local Meetup (obviously) existed and was part of the WordPress Meetup programm named “WordPress Meetup Nürnberg”. Same already existed years earlier for “Köln” vs. “Cologne” which might be even the first to be exposed to this issue.
German umlauts can be part of a TLD, but are still quite rare and when it comes to the complete URL they simply don’t exist. The usual way to solve this is to write “ä” as “ae”, “ü” as “ue”, “ö” as “oe” and “ß” as “ss”. WordPress in german language setting does this by default when it comes to build the slug. Writing about the Cities of “Düsseldorf”, “Würzburg”, “München”, “Köln”, “Osnabrück” or “Nürnberg” therefore would be solved when the names appear in post-titles.
How to name them, when it comes to categories? Which is the case for publications on WordPress.tv which clusters videos by the location. Esp. with the naming conventions for URL namespaces in mind and the definition to use the english naming for events, regardless of the local name and – of course (see above about urls) of the local alphabet. At the moment we find different settings:
Local name and english name of the City is the same – the easy part. Just name it and of you go. True at least for all english speaking countries.
Local name and english name differ, but use the same alphabet. This is not only the case for German, but other languages based on the latin-alphabet. (en: Antwerp/be: Antwerpen). This case is tackled in different ways. Sometimes the local name is used (München, Würzburg, Norrköpping), sometimes the english one (Antwerp) and sometimes both exist as seperate categories (including some inconsistencies about the number of publications) side-by-side. Like for Köln/Cologne, Nürnberg/Nuremberg, which brings us back to our first question. But there’s more:
Local name and english name differ in alphabets used. This is true for all Cities in Countries using cyrilic, korean, hindi, chinese, kanji and other alphabets. At the moment all of these are written in the english.
Sidenote: as wordpress.tv is setup in english, the slugs don’t reflect the correct umlauts at all. “ü” is transformed to “u” instead of “ue”, etc.
Second idea would be to use just english names, which – maybe due to my new Kenyan home – feels a bit “colonialistic”.
Just using local names might not be useful at all in a global context.
This said, my suggestion would still be to come up with a naming which reflects both the english and – where it applies – the local name in one category, even if this would include different alphabets. The categories name for cities therefore would be something like:
{english name}[/{local name in their respective alphabet}]
for the title and
{english name}[-{local name in their correct transformation}]
for the slug. This would melt down the usage of the a.m. double categories to one only each and still would give enough local flavour and identity. Coming back to our original question therefore would have “Nuremberg/Nürnberg” as one category. The slug should read “nuremberg-nuernberg”. Moscow e.g. would be “Moscow/Москва” by title and “moscow-Москва” for the slug.
Hi @stk_jj Thanks a lot for publishing this. As polyglot I am of course a big fan of having the name in the local language too.
1. Moscow/Москва is very nice. I’m just wondering if that should go into the same field or in 2 separate ones (so English name and native/local name like we do e.g. on http://wayback.fauppsala.se:80/wayback/20211001165728/https://make.wordpress.org/polyglots/teams/ ). Keeping it together would show it immediately everywhere so might be the easiest option. If we make it 2 fields it would require coding.
2. For the slug we would however have to stick to English only. It might be because of my programming background, but slugs should be ‘easy to handle’. But of course that is my personal view.
Hi @stk_jj and thanks for raising this question.
About the slug I agree with Pascal that probably the best solution is to leave it in English, the slug is a “technical” info, so I think the priority is to choose the best solution in terms of code and compatibility since It’s not an informative part.
The categories, however, are, so I agree with the proposal of one tag with the two versions together.
Thinking about the Italian language, but It applies to many other languages: for some cities we have the double version: Milan/Milano, Rome/Roma and so on. For others we don’t: Verona, Catania, Bari…. In the first case the category will be Milan/Milano and it’s fine. In the second we don’t have an English name so I assume the category will be formed of only one name, is it correct?
Unless we implement full localisation on the site, we’re primarily targeting a global audience, and therefore English is a sensible primary/default language.
Slugs should be English only, for maximum compatibility and standardization. Adding both variations into a slug adds complexity for users and consuming systems.
I’d recommend adapting the structure of category names ever-so-slightly to {english name} ({local name}) , so that it’s explicitly a two (or more) separate words.
Thanks for this valuable feedback. Just for my understanding: a space between the intl. and the local name instead of whatever divider (slash, dash, …) is the better option? What about intl. space divider space local? Esp. when a name consists of more than one word it might be easier to read.
Thanks @lorenzof, @jonoaldersonwp, @casiepa for your thoughts and ideas. I think we can conclude that {english name} ({local name}) seems to be the best solution for readability, seo-matters, etc. etc. I’ll take care of that, so that we can terminate this topic.
First of all thank you to have voted for your new team reps. I’m happy to announce that Nisha Singh (@nishasingh) and Rahul D Sarker (@rahuldsarker) have been chosen by all of you. Congratulations to both!
We will be continuing this journey together to guide you all in WordPress.tv world.
Rahul D Sarker (@rahuldsarker) (the names will be shown in random order on the form)
Thanks already to all 3 wanting to take the role!
The form is requesting Google credentials (to avoid people by accident voting twice). If you don’t have them, contact me directly to cast your vote and I’ll make sure it gets added.
All responses will be viewed only by Michael and myself (Pascal) and all data will be destroyed shortly after the announcement of the outcome.
When uploading a subtitle on WordPress.tv, the list is taken from VideoPress. Check the full list by inspecting any video page :
YouTube has the most complete list, based on ISO639-1 two-letter codes, and also accepts locales like fr-ca:
Proposal
Languages are pretty stable and, ones set, hardly need a change. A tag as it is today would be sufficient, but it should include the unique codes of all different platforms. Languages should also be added ONLY if they exist on both VideoPress and youTube. If a locale does not exist (fr_BE), but the ‘main’ language (fr) exist, then that could be accepted of course. So the following tags could be created:
Name (English)
slug
wp
glotpress
videopress
YouTube
French
fr
fr_FR
fr
fr
fr
French (France)
fr-fr
fr_FR
fr
fr
fr-FR
French (Belgium)
fr-be
fr_BE
fr-be
fr
fr-BE
Spanish
es
es_ES
es
es
es
Spanish (Spain)
es-es
es_ES
es
es
es-ES
Spanish (Argentina)
es-ar
es_AR
es-ar
es
es-419
A dropdown with the above English names could be used on:
The proposed name/slug/value approach looks great.
We don’t need fr and fr-fr – we can collapse those down into the generic parent.
We’ll need to make sure any altered/deleted URLs (the categories, and any videos/pages which were in them) execute a 301 redirect to their new URL.
If we’re feeling more ambitious…
It’d be preferable from an SEO perspective to internationalise the whole site, and remove the /language/ component (thus moving the language slug to the root; e.g., http://wayback.fauppsala.se:80/wayback/20211001165728/https://wordpress.tv/fr-de/{{pages}}/). We could then also provide translations/localisations of individual videos much more cleanly and scalably.
It occurs to me that there are plugins which handle this gracefully (e.g., MultilingualPress, WPML, etc).
Concerning We don’t need fr and fr-fr – we can collapse those down into the generic parent. , should we call it ‘French’ or ‘French (France)’?
For the /language/, note that this is not indicating in what language we want the site but shows all videos that we have where that language is spoken. It’s a WordPress category. So if we switch from /language/germandeutsch to /language/de, then /language/germandeutsch will act just as /language/whateverweputhere
But let’s see if there is an easy way to put a 301!
Hmm. ‘French (France)’ gives us some consistency if we have languages with only one ‘version’, but later decide to expand out? I like that it explicitly demarcates the language/locale!
From language perspective, probably the best solution would be to keep all the locales to specify exactly what dialect is used, for example Belgian French or French French. The data would be correct and it would follow the best practices.
From a usability perspective, however, is it really necessary to distinguish the dialect, given that maybe the speaker isn’t native, or it can be difficult to know exactly which dialect is used?
For example, I’m italian and if I gave a speech in English, what language code would I use since my English probably is a mixed English?
Moreover, the locales probably would generate many wrong data, because to have some precise data the uploader must know the exact dialect the speaker used, and it’s not always clear. And again, if the video is edited and uploaded by us, there’s even less chance that we can recognize it.
These are Just my thoughts, I think there’s not a wrong answer, my opinion can be questionable under some aspects, but better consider everything before making a choice
I also agree @lorenzof that people will watch videos in other variants. I was chatting with @tokyobiyori about this and she agreed too (about Spanish) 🙂
I’d watch English videos from UK, Australia, India, or any other countries.
Locales may not be as important in this case?
Countries as another type of taxonomy may be more relevant so that people can find all contents from, for example, Belgium/Switzerland.
It’s not an easy process, there are many things to consider, but let’s continue these talks, we will eventually find the best solution (or at least the most reasonable one 😉 )
Thanks for the precious info Ian! About the YouTube public form the idea is that the video doesn’t automatically publish via the form but when submitting the form, the video goes to draft where it can be manually reviewed by a mod.
Last year the discussion around YouTube and willingness to include YouTube into our current process for bringing videos to the WordPress World has increased, so the time has come to get some ideas together and find a way to embrace new ways of sharing and viewing videos, and collaborating on e.g. subtitles in different ways.
If you have ideas, have experience in other projects related to this or even just want to listen, please indicate your preference on this doodle so we can schedule our first YouTube brainstorming.
The link to zoom will be given on the slack#wptv channel some time before the start.
Notice/disclaimer: I will record the meeting, but only for the purpose of my personal notes that I want to create at the end.
Please indicate your preference in doodle before Tue 11-Feb 09:00 AM Central European Time.
Hello Pascal,
That’s good idea. My suggestion would be that the same form that we have in WordPress.TV, adapt to upload the same videos to Youtube Channel. Even have two files: one compressed and one uncompressed. The compressed would upload to WordPress.TV and the uncompressed would be uploaded to the Channel.
Because this form is the way to submit videos, that would be the best idea in order to not confuse our contributors.
Hi @stk_jj Thanks a lot for publishing this. As polyglot I am of course a big fan of having the name in the local language too.
1. Moscow/Москва is very nice. I’m just wondering if that should go into the same field or in 2 separate ones (so English name and native/local name like we do e.g. on http://wayback.fauppsala.se:80/wayback/20211001165728/https://make.wordpress.org/polyglots/teams/ ). Keeping it together would show it immediately everywhere so might be the easiest option. If we make it 2 fields it would require coding.
2. For the slug we would however have to stick to English only. It might be because of my programming background, but slugs should be ‘easy to handle’. But of course that is my personal view.
I’m a big fan of KISS – keep it simple, stupid. Therefore: I would be fine with both in one field.
Re. slug – see below
Hi @stk_jj and thanks for raising this question.
About the slug I agree with Pascal that probably the best solution is to leave it in English, the slug is a “technical” info, so I think the priority is to choose the best solution in terms of code and compatibility since It’s not an informative part.
The categories, however, are, so I agree with the proposal of one tag with the two versions together.
Thinking about the Italian language, but It applies to many other languages: for some cities we have the double version: Milan/Milano, Rome/Roma and so on. For others we don’t: Verona, Catania, Bari…. In the first case the category will be Milan/Milano and it’s fine. In the second we don’t have an English name so I assume the category will be formed of only one name, is it correct?
Thanks!
yes – naming of the Italian cities would be as described.
Regarding the location I had mainly this in mind:
http://wayback.fauppsala.se:80/wayback/20211001165728/https://wordpress.tv/category/location/nuremberg/
It would be nice (esp. in terms of SEO – maybe some with more background on that could correct me) to have both names in here
Hello!
Some SEO considerations:
{english name} ({local name})
, so that it’s explicitly a two (or more) separate words.Thanks for this valuable feedback. Just for my understanding: a space between the intl. and the local name instead of whatever divider (slash, dash, …) is the better option? What about intl. space divider space local? Esp. when a name consists of more than one word it might be easier to read.
@stk_jj from my understanding for SEO purposes a space really indicates a new different word, a slash does not. So:
Are both great where
would be less good for readability
My bad. Didn’t see the brackets. Indeed this seems to be a good solution for both readability / usability as well as SEO
Thanks @lorenzof, @jonoaldersonwp, @casiepa for your thoughts and ideas. I think we can conclude that {english name} ({local name}) seems to be the best solution for readability, seo-matters, etc. etc. I’ll take care of that, so that we can terminate this topic.