W przerwie między tłumaczeniem… właśnie trwa runda tłumaczeń OpenSUSE 11.1. Termin mamy do 18tego, więc zostało jeszcze trochę dni i trochę plików do tłumaczenia. Ja dopiero dziś znalazłem czas i usiadłem do tego, ale staram sie nadrobić 🙂
Jeśli ktoś ma wolną godzinkę i chce pomóc, to zapraszam na Wiki tego tłumaczenia.
I’ve just added OpenID support to Community Wiki. It should make it easier for people to edit the wiki, but its also a step in the direction of Mozilla Community Sites package.
I will write a separate post about MCS, but as many of you know since Fx Summit, I’m working on the set of customized open source web apps that will make setting up a community website much easier. One of the webapps that will be offered is MediaWiki, and one of the features of all the tools will be support for OpenID. Using this on Community Wiki is just a first step 🙂
For last two months I have been working on a project that has been in my mind for over 4 years now.
Originally, the idea of what we called a Community Pack appeared during Mozilla Europe Board of Directors discussions between me and Pascal and the first notes drafted by us are located at old MoEu wiki.
Today I’m proud to announce the wiki that one day may become an official community/contribution website for Mozilla. It’s very early in the game, the theme is just something I crafted temporarily, the name has not been decided yet, the structure of the categories may change.
What is there, is an idea with a groundwork already started. The purpose for the website is to help new contributors learn about various activities inside our project and smooth the learning curve.
Beside, the wiki should help people create their own communities, improve community-2-community experience and knowledge exchange. We will try to help smaller communities learn what mature communities know, share the materials we have and address the potential that lies in strong, independent communities existing inside the Mozilla project.
The wiki will not duplicate any material that exists anywhere. It will serve as a kind of roadsign to all the various materials in different places. Wiki.mozilla.org, MDC, SUMO, QMO, SpreadFirefox and others. It’s a Wiki because we want to b
e able to add content in cases where we don’t have where to link to.
The structure of the main page represents the activities that are part of Mozilla, not projects because people who are new to Mozilla don’t know the names of the projects, but will be able to select the activity they’re interested in.
The temporary URL to the front view of the Wiki is http://como.labs.braniecki.net/ but it’ll of course be moved to Mozilla servers pretty soon.
The back end, for editing is http://como-edit.labs.braniecki.net/.
It’s not a perfect solution, but I had no time to work on the skin to make it present all the UI of MediaWiki, especially the theme will be reviewed to m
atch Mozilla sites guidelines.
What now? Well… it’s up to you! First, do you like it? Do you think it may be useful? We want to grow this roadsign, so we want to add urls to your community websites there, to all resources inside Mozilla, and add content in the places where its missing. The one section that requires a lot of work is Community building.
If you are interested in helping, just create an account and start editing! Don’t be afraid of changing thing, we’ll review them.
I will be working on adding content to missing pages, since I’d like all main “category” pages to look at list like Accessibility or Localization. In the next weeks I will be also working on Mozilla customized web tools and Community Website Theme that will help you create new community websites. 🙂
Wczoraj Mozilla ogłosiła prace nad silnikiem TraceMonkey. TM jest modyfikacją aktualnego silnika Gecko – SpiderMonkey, do którego dodana została opracowana przez pracowników Uniwersytetu Kalifornijskiego implementacja algorytmu JIT. Nie jest to może żadna czarna magia, po prostu opóźnienie wykonywania skryptów JS (każdy kto pracował z JS wie, jakie ograniczenia wydajności JS nakłada – nikt raczej nie pokusiłby się o tworzenie silników graficznych 3D w JS) jako interpretowanych jest tak duża, że okazało się, iż opłaca się skompilować wstępnie kawałki kodu JS i w przypadku występowania powtarzających się procedur odpalać skompilowane fragementy zamiast interpretowania kodu na bieżąco.
Efekty są bardzo wydatne.
Każdy kto śledzi planetę Mozilli widział już wykresy Brendana, Shavera i Schrepa. Ja wykonałem małe testy na benchmarku Dromaeo autorstwa niezrównanego Johna Resiga.
Wykonałem dwa testy – w Fx 3.0.1 i dzisiejszej kompilacji nocnej z włączonym JIT dla treści stron.
Wynik dla Fx 3.0.1, Wynik dla Minefield trunk i wynik porównania dwóch. Przyspieszyć o kolejne 46%? Nieźle… co? 😉
Najlepszą informacją w tym wszystkim jest to, że Brendan twierdzi, że JIT powinien być szybszy w dokładnie każdym teście. Jeśli gdzieś nie jest, jest to błąd i będą to teraz poprawiać… Całość implementacji zajęła 60 dni i jest to wersja bardzo wstępna, najbliższe miesiące powinny przynieść kolejne przyspieszenia wraz z optymalizacją nowych możliwości.
Co z Tamarinem? Tamarin to znacznie bardziej poważny eksperyment, wymagający dużego nakładu pracy. Ma być on podstawą silnika ActionScript, który zastąpi obecny w platformie Mozilla 2 (i w efekcie w Firefoksie 4).
Obecnie prace nad nim trwają w osobnym repozytorium na hg.mozilla.org, i zostanie on włączony do mozilla-central prawdopodobnie po wydaniu Fx3.1. Tamarin ma być oczywiście znowu, znacznie szybszy od TraceMonkey (gdyż będzie korzystał z jego dobrodziejstw i dodawał kolejne), będzie też pierwszą implementacją języka JavaScript 2.0 (który dla mnie jest przede wszystkim pokornym wzięciem największych dobrodziejstw Pythona:) ) ale można go już dziś przetestować kompilując tamarin-central.
Kolcami tej róży są problemy z debuggerami. JIT sprawia, że cały proces interpretacji przestaje być deterministyczny i nie za bardzo wiadomo jak to obejść. Na razie przy włączonym Venkmanie, Gecko wyłącza JIT, ale nie jest to optymalne rozwiązanie i będzie trzeba poczekać, aż Gijs wróci z wakacji i podejmie decyzje co dalej z Venkmanem…
Jeśli ktoś chce włączyć JIT, to może to zrobić na dwóch poziomach – dla stron i dla samego Firefoksa (about:config i szukaj “jit”). Włączenie dla Firefoksa oczywiście znacznie poprawia jego wydajność (duże części Fx napisane są w JS), ale jest w tym momencie dość ryzykowne. Natomiast dla stron jest dość stabilnie (zanotowałem kilka wywaleń w Gmailu i Facebooku tylko) i z każdym dniem będzie lepiej 🙂
Docelowo, w ActionMonkey i Mozilla 2, celem Mozilli jest aby jak najwięcej kodu było pisanego w JS, a wydajność JS była porównywalna z kodem kompilowanym (C++)… Coś co wydawało się niemożliwe, nie tylko stało się realne, ale jest aktualnie celem programistów w projekcie Mozilla. Mam nadzieję, że się uda 🙂
Ostatnio pojawiły się artykuły na temat kilku projektów wewnątrz Mozilli mających pomóc unowocześnić Internet Explorera, “No browser left behind” Vlada dodający Canvas do IE, czy ScreamingMonkey dający obsługę nowoczesnego JavaScriptu (w założeniu JS2.0) w IE.
Dostałem kilka maili z pytaniami w tej sprawie, parę osób podpytało na Jabberze, a na vortalu DobreProgramy komentatorzy spędzają czas radośnie próbując znaleźć wytłumaczenie dla tego ruchu.
Co ciekawe, wśród tak wielu teorii ukutych na prędce zabrakło tej jednej, rzeczywistej. I wydaje mi się to bardzo symptomatyczne dla współczesnego myślenia, że tego typu wytłumaczenia rzadko przychodzą do głowy.
Wytłumaczenie to brzmi – celem statutowym Mozilli Foundation jest promocja wyboru i innowacji w Internecie.
Takie trudne? My nie walczymy o zajęcie rynku przez naszą przeglądarke. My walczymy o to, aby Internet sie rozwijał i uznaliśmy, że optymalnym sposobem do tego jest stworzenie i promocja przeglądarki, która zagwarantuje rozwój Internetu w modelu opisanym w Manifeście Mozilli (tłum pl w trakcie prac).
Mozilla jest otwartym projektem i działa bardziej jak Bazar, czy środowisko naturalne, niż jak Katedra – zorganizowana i uporządkowana. Wiele rzeczy to inicjatywy oddolne i tak jest w tym przypadku. Ludzie wewnątrz projektu chcą poprawiać świat i jeśli Vlad zauważył, że przeszkodą w adaptacji technologii Canvas jest brak jej wsparcia w IE oraz udało mu się opracować jak to dodać, to jest to idealnie wpisane w model jaki chcemy promować w Internecie.
Tym właśnie, tą różnicą w podejściu, tym, że celem nr.1 każdej firmy są pieniądze, a standardy, otwartość, użytkownicy są środkiem do tego celu, a u nas jest, z definicji fundacji non-profit, odwrotnie wyróżniamy się na rynku i to czyni naszą odpowiedzialność ogromną, a naszą pozycję i nasze możliwości unikalne.
Just a quick note for all stakeholders: silme has been moved to hg.mozilla.org.
First update after public announcement. During last week, Silme received several minor stability patches in trunk and got initial support (patches [1], requests, feedback on API) from several developers including Stefan Plewako from Aviary.pl and Flock projects, Adrian Kalla from Aviary.pl and an intern in Mozilla Corp., and Pike himself 🙂
Beside of that I spent some time during Firefox Summit on talking with people of Pootle/TranslationToolkit fame to identify potential problems that they faced. It was extremely supportive for me and gave my major take away is that if I want to reach my goal of having one, common abstraction layer for l10n objects I have to merge two very different concepts – single locale files (like DTD, properties, ini) and multi-locale files (XLIFF, GetText, tc).
Multilocale branch has been ignited to address this. I already did several tests and it seems that I will be able to support both models in one API without making both feel like hacks.
Pike raised another concern, that I tried to keep for later which is a concept of entity/l10nObject processing. Initially I assumed that it’s a minor topic, and on this level of abstraction I assumed that leaving the entity values unprocessed is OK for now. Unfortunately, especially with L20n being the next Big Thing for Silme, entity processing becomes very important and has to become a legimate element of the library skeleton.
I started early hacks of l20n.py format parser leaving my brain in free conceptual thinking mode and waiting for Pike’s time to talk about grammar inconsistencies.
Last big thing to come is a soon to happen switch from svn repo on my server, to shiny new hg.mozilla.org. This requires me to spend a few hours on svn-to-hg migration tools, but should help with later branching and support easier collaboration between many developers.
Current roadmap is pretty dense for stage3, and may be latter splitted, but does not currently involve work on end-user oriented apps like a webtool. Once I have this two major restructurizations ready (multilocale/pre-processing), I’ll get back to providing proof-of-concept tools. We’re of course looking for more developers so let me know if you’re interested 🙂
W środku zlotu społeczności Mozilli w Whistler, BC, Kanada, na jedyną drogę łącząca Whistler z Vancouver spadła lawina.
Staramy się nie stracić pogody ducha. 🙂
Lekcja na przyszłość – nigdy nie wybieraj na miejsce spotkania miasta, którego nazwa jest nazwą kodową Microsoftu…
Update: Teraz jeszcze jakaś ciężarówka przecieła linie i nie mamy prądu w hotelu… robi się ciekawie 🙂
Few minutes ago Tristan and I delivered a presentation on Mozilla presence in Europe and because not everyone could join us, I was asked to push our slides online. Here you are:
Enjoy 🙂
Last half a year was amazing for me. I joined Mozilla Corp., reignited my participation in Mozilla project, worked on several exciting projects and it’s an amazing coincident that this half a year is almost over exactly now, when I’m sitting at Whistler, with 400 creative, innovative people and we’re all listening to Mitchell Baker speaking about our open source roots, and the trunk of the project being about “Human interaction with the Internet”… It’s thrilling.
There are several projects that I’m trying to launch related to Mozilla, I will be speaking about them during the Firefox Summit, and I will blog about it once the summit people share their feedback on it.
One of the elements of Mozilla ecosystem that has been super exciting for me is localization and internationalization. And the great news is that there’s a lot happening around L10n in Mozilla these days. We’re improving the l10n build system, l10n processes, but there’s one very visibly missing area in L10n land – tools. We finally have a project that is going to target this – Verbatim. Verbatim is a project aiming for a webtool that will allow localizers focus on the translation instead of having to spend time trying to figure out how to do the actual translation. If you’re in Whistler, we have a presentation on Verbatim today 🙂
But that’s not all! There is one project that was something I’ve been coding over weekends and while at the airports and on flights and in many other places. It’s inspiring and challenging for me enough to keep working on it over evenings, nights, sundays, and holidays which I have to apologize for to my girlfriend 🙁
Yesterday, I tagged stage2 of the project which means it’s more or less ready to go public and be reviewed by you all, and has a chance to explain itself to the level that may attract others to join me and participate in it.
The project name is Silme, and it is a python localization library that has been structured in a multi-abstract level model. Thanks to it, the library works natively with DTD, Properties, GetText, can work with XLIFF, L20n, ini files and any other l10n data format. Beside, it can work with files stored on drive, in SVN, in CVS, in MySQL, SQLite and virtually any other data source.
On the other hand it’s extensible and flexible enough to work in web app, command line tools, or GUI tools. It’s not only for Mozilla, as any other project can build apps on top of this library. Be it Songbird, Miro, Seamonkey, Firefox, Thunderbird, Addons.mozilla.org, Flock, GNOME, KDE, etc., etc.
If you find above description interesting, please read the original announcement and join the project. It’s totally open and very alpha. If I try to express where I am with it, I think I just passed the mark when the code self explains the idea. Nothing more.
Beside, it’s a lib. Unless people like to localize directly in python env, we need apps on top of it. And it’s at least as challenging as a library itself, but if you want to write a localization app, I think it’ll be easier if you will be able to focus on UI and features of the app, and minimize the work on sole entity operations that Silme does cover.
So… here we are. I’m confident I will keep working on it, and some small simple apps will be created for my own use, but it’s very, very far from being useful, and need a lot of work to get there. Ultimate goal will be to work smoothly with an exciting project that is being mindcrafted in Mozilla these days – L20n.
Please, remember that it’s a hobby library for now, a product of several years of work as localizer, countless nights spent with my friends from Aviary.pl – Polish Localization Team, and the creative environment of Mozilla project. It’s up to you all what will happen next with it 🙂 So mail me, or reach me on IRC if you want to discuss things about possibilities that Silme opens!