YOURLS 1.6 : translators wanted !

Change of plans for YOURLS 1.6. According to the RoadMap and previous posts here, the upcoming version 1.6 of YOURLS would introduce a new DB schema. But plans are made to be changed!


Localization has always been a long wanted feature for YOURLS (issue #58, opened more than 3 years ago in September 2009). It has always been planned, but low priority. Then, two things happened.

First, a couple month ago, I had to set up a YOURLS instance on a French corporate intranet. It immediately occured to me that the lack of translation API was going to make things a little more complicated than expected, given all the strings that were hardcoded in English. I always picture individual users such as myself not having a problem using simple software in English, but it’s a little different when you have to deal with a larger non-techie population.

Second, recently, @LeoColomb, a long time YOURLS user and prolific hacker, threw a patch in my face with the first draft of the translation API. Yep, in my face!

So, I decided to prioritize that feature. Over the last few days the committing pace has been unusually hectic and as of now, labelled 1.6-polyglot, YOURLS is ready to be fully translated.

Translators Wanted!

What does “ready for translation” mean exactly?

Instead of having hardcoded strings, such as echo "Woah awesome" and return "You are nice", YOURLS now uses the very common gettext functions, and you’ll see code like yourls_e( 'URL added' ) and return yourls__( 'You are nice' );. These functions search for the translated string in a translation file, if available, or otherwise return the original string.

More detailed documentation to help translators will be written later, but it’s a really straightforward simple process:

  1. Download YOURLS.pot, the translation file template
  2. Rename it to [your-locale].po, where [your-locale] is typically language code, underscore, country code (for instance in Portugal that would be pt_PT, while in Brazil it’d be pt_BR).
  3. Install a translation software: it’s nothing more than a text editor capable of reading .po files, showing you the untranslated string and a text box where you type in the translation, and saving a .mo file which is what PHP needs. A cross platform, simple yet complete editor is Poedit. There are also simple web based tools, such as PoEditor where you upload the .pot, translate, and download a .mo
  4. Once you have your fully translated pt_BR.po and the generated, host them somewhere (preferably on a source control enabled environment such as Github or Google Code to make contributions easier) and ping me! I’ll maintain a list of available translations.

To test your translation file as you create it :

  1. Download a nightly build or update via SVN
  2. Drop your pt_BR.po and files in user/languages
  3. Add define( 'YOURLS_LANG', 'pt_BR' ) to your config.php
  4. That’s it! Play with YOURLS

Translators, it’s important you join the party early: you’ll help us make sure the translation API works as smooth as expected, and win the “First YOURLS Translation Ever” award :)

What’s the Roadmap, then ?

On top of localization, which not everyone gets excited about, YOURLS 1.6 will bring the usual load of bugfixes and little enhancements. Better URL sorting and searching in the admin interface, more filters and actions to allow for more flexible and powerful plugins, a smarter API, better security and sanitization functions, plus more awesome and more w00t.

As usual, no ETA, but we’re speaking probably a couple weeks here. It really depends on the translator feedback.

Then it will be time to work on YOURLS 2.0 with the much awaited and needed DB structure change, and more goodness you’ll be able to handle. From a semantic versionning point of view, it just made sense anyway to give such a change its own major release number rather than a simple dot release.

There are even more news to share, but that’ll be another post :)

Short URL to this post:

Working on YOURLS 1.6 : the next DB structure

What’s up, gents? I’ve begun working on the next iteration and here’s what I’m up to.

YOURLS 1.5 : DB suckage

As everybody knows, the current database design in YOURLS is dumb and very inefficient. Its biggest flaw is that the keyword (ie short url) is repeated in both the URL and the LOG tables, making it absurdly difficult to update a short url without losing all historical data.

Another design decision I regret was to store stuff in case they would be useful to anyone, such as user agents in the log table. Since there’s no core feature using that info and I probably won’t implement any, this should not be there. There’s a plugin API for this.

There are a couple of awesome features I want to work on for YOURLS 1.6, one of them being the ability to store arbitrary data associated to any short URL — think url meta data, the way WordPress does it.

YOURLS 1.6 : previous thoughts

I’ve been pondering about the next DB schema for a very long time now, trying to think about the most state-of-the-art structure I could come up with (given my overall blatant lack of skill for DB things) and addressing all possible future features and current issues. I’ve proposed stuff and a few people have been kind enough to comment. But all this had one weakness : it was complicated and scaring me. Seriously :)

YOURLS 1.6 : smarter yet simple (at least I hope so)

I decided to make up my mind once for good and here is how I see things in YOURLS 1.6:

The main URL table will be properly normalized with a URL id to stop repeating the keyword across tables. I could probably go further in normalization (storing the long URL and title somewhere else, as I first thought) but that’s where I think it becomes too much trouble and hassle for too few benefits.

The URL_META table will store anything you’d like about a particular short URL and will be used by plugins: some tags, a note, a mime type to handle redirection differently, anything.

The LOG table will be trimmed down a bit, which — disk wise — should be beneficial to sites with lots of hits, and properly. Again here I could probably go further and normalize the referrer information, but what bothers me then is the number of DB queries needed for each short URL redirection, which I want to keep at a very minimum.

The LOG_META table, just as its meta sibling, will store anything you’ll want to store about a hit: the user agent, some cookie info, anything.

No big change in the OPTIONS table, just an autoload parameter so plugins will be able to store anything without loading that every time in RAM.

So, that’s it. If you have any thought or any “zomg dude don’t, terrible decision” warning to share, please do. We’ll see later for other DB novelties such as log archives or further optimization. I’d rather stop pondering and start coding :)

Short URL to this post:

Future Database Structure

Even though the 1.5 version is not ready yet, I also have in mind the next release, 1.6, which will introduce a much needed DB rethinking. Currently the DB schema is very weak and inefficient, making it difficult to introduce new features and having lots of redundant data. Another effect of the “never thought this project would get that big” syndrome.

What I have currently in mind is this schema:
DB schema v2

Comments welcome on the wiki page to keep things in one place.

Short URL to this post: