Webird source is now available

Webird source is now available. I'm still making a lot of changes to it as I push from my notebook and pull from my VPS. At this point I'm working on work flow improvements and optimizations but I'm still finding a few bugs here and there.

Please don't base anything long term off of the code base as it is changing quite a bit and it will be improving in incompatible ways.

I'll be releasing some instructional and feature videos when I can be fairly sure that I won't be changing it so much.


I have access to a translator for German, Russian and Ukrainian so I'm working through the process of adding these languages to Webird. It is a good thing that I'm doing this since it wasn't working correctly for any language other than en_US. It was reading the en_US po file for that locale only.

Another issue involves purging the gettext cache. Its rather easy to read working code for this but its rather difficult to get it working since gettext doesn't report much about what it attempted to do. Additionally much of the documentation seems to not properly mention how to use UTF-8 encoding and I was suffering from an extra '-' in there. Apparently some blog post was wrong about that, even though it matched the output from locale -a on the command line.

I've implemented a nice fallback mechanism in the Javascript for using more generic codes like 'en' if they are available but it doesn't seem to be possibe on the gettext side of things from what I can see. I think that it would be much easier to maintain languages if there was an optional default for each language.

edited Nov '14

I'm creating a locale class to determine the best language according to all the specific rules that Webird needs. The current solution will not work adequately since Webird treats the CLI interface as a first class citizen. There is trivial stuff like converting dashes to underscores and more complicated stuff like providing language fallbacks and a language default. The idea is that you can define 'en' to default to 'enGB' or 'ru' to 'ruRU'. For example: who wants to deal with maintaing 'ruRU' and 'ruUA'? The possibilities are very large and my solution will allow people to specify generic languages and more specific languages.

One big issue is that gettext doesn't give much in the way of error reporting when it fails. In one way its rather nice as it will just use the English strings, but I think that I can do quite a bit better than that. My argument is that supporting a new language can be quite a stretch on the resources anyways without needing to take into account all of the tribal bickering on the matter. Gettext doesn't provide shit in the way to help this. I could check to see that the gettext binddomain function fails (returns not a path) but that would mean putting a lot of logic into the Gettext class. I'll consider implementing this but it seems pretty hacky and I'm weary of hacking everything togther with tape.

Interestingly, Nodejs webpack provides a rather nice solution for this by creating a runtime exception in the browser when a specific language locale can not be found. By catching this exception it is easy to walk through the possibilities until finally giving up and going with the default language.

For now on the PHP side I'm forced to scan the directory while in development mode to determine the available locales. I could store this in the locale.config but I'm trying to keep the locale config DRY since that data is already available in another form. Don't worry though because the available locales will be burned into the final dist/build config.

  "default": "en_US",
  "fallbacks": {
    "en": "en_US",
    "ru": "ru_RU"
  "maps": {
    "todo": "TODO"

After I have this bit of work done I'll tag Webird as 0.5 and then when that dust settles I'll be making some videos to show off all of the features and the tight front and back end integration. Otherwise without the videos I think that people will miss about 80% of the point of Webird.



I think you provide url demo, it will for details clearly


@Thiện try http://webird.io.

I disabled guest registration code from Vokuro but I'll be adding it back shortly. If you want to get a feel for it then check out the way that JS is loaded with Webpack by using the browser console. Its doing something far more advanced than require.js for example.