Here is the updated version of the search guidelines for Fennec:

5 standard search engines:

You should choose only 1 search engine in each of the following categories.

• Global general search
  • ‘Regular’ global general search, much like in desktop Firefox.
• Reference search
  • Almost all of the time, this will be Wikipedia.
• E-commerce search
  • Both to shop on-line and to consult product information.
  • Store preferred over auctions.
• Local search
  • I.e., “around me” search; e.g. “find the nearest ATM”.
  • Only if available in the region.
• Social search
  • I.e., microblogging platforms/feeds, social networks (no invite-only sites).
  • Only if relevant in the region.

1 extra search engine:

You can choose to use it if no e-commerce/local/social search is available.

• Specific interest search
  • Something specific to the region, reflecting the local way of using the Web.
  • Can be from different categories: e.g. reference (a dictionary or a word reference recommended), entertainment (imdb, youtube, music search), e-commerce (price comparison), general search provider very popular in the region, etc.

The maximum number of search engine plug-ins is 5. Each search engine should be chosen from a different category, as listed above. In rare and well justified cases, we might go for 6 plug-ins total—the sixth one would be then an engine from the additional specific interest category. You can add a specific interest search engine also if there is no e-commerce, local or social search that you would recommend for mobile Firefox for your locale. Or, you can choose to go with fewer plug-ins, which is totally fine, too.

For more context and rationale behind these choices, please take a look at my previous posts on Fennec’s productization.

As always, comments are more than welcome.

Litmus is a great tool used by our QA community for testing purposes. With a wide range of test cases grouped in test runs, it’s probably safe to say that it covers all aspects and features of Mozilla products. You can read all about Litmus over at QMO, in the Litmus tutorial.

If you want to test your localization of Firefox 3.5 using Litmus, the best place to start is the 3.5 l10n test run. It’s a great way of giving your testing a structure, which will help make sure you cover all localization. It’s also very helpful when testing periodically—by following the test run, you’re sure not to miss anything that you tested last time.

To do a Firefox 3.5 l10n test run for your locale, go to the Firefox 3.5 l10n localizer test run on Litmus and sign in. You can also created a new account if you haven’t already. Or, go to litmus.mozilla.org and choose Firefox 3.5 l10n localizer test run from the list of active test runs. (You may have to click View all available test runs at the bottom of the page first.)

Next, fill in your Build ID, Platform and Operating System, and, most importantly, your locale. Click Submit configuration. On the following page you’ll see testcases subgroups available in this test run. Right now there are no testcases in the RTL (right-to-left) subgroup, so just click Submit in order to proceed.

As of this writing, there are 23 testcases to go through, and for each of them you can indicate a result: not run, pass, fail or test unclear/broken.  Please leave a comment when a testcase fails or the instructions are unclear or outdated.

When you’re done (you don’t have to do all testcases at one time), just click Submit All Results. Congratulations, you’ve just contributed to the testing efforts to ensure best quality of your localization!

There are other test runs available on Litmus, many of them more detailed and more thorough than the l10n test run (e.g. the catch-all test runs). You’re encouraged to perform these tests to provide even more testing coverage for your locale, but generally they’re not required to move a locale out of beta.

You may also be interested in seeing how much testing has already been done for your locale. It’s simple. Just go to the Search Results page, choose your locale on the far right and hit Show Results. You may also want to specify the product, branch and platform, as well as the timespan (e.g. show only tests performed in the last 2 weeks).

If you’d like to have more information about how to use Litmus, be sure to check out the tutorial on QMO. If you have questions, don’t be shy and do ask us in #l10n or #qa.

This quarter, the l10n drivers team has set out on a mission to improve the current localization documentation experience. The ensemble of the l10n documentation consists of a rather formidable number of resources (wiki documents, articles, blog posts, graphics, etc.). With time, some of them have unfortunately become out-of-date, and one of our objectives is to update our documentation to reflect the changes that took place to our processes, practices, policies, guidelines, tools and infrastructure (like, remove references to CVS in documents about starting new localizations).

But that’s not our only objective. A big goal that I see here is to identify who’s using the l10n documentation (localizers, l10n-drivers, qa, bizdev, build, developers, webdev, marketing… and so on and so forth), and with these targets in mind, reorganize the documentation in a way that would best serve these groups in completing the task they come to the l10n documentation with.

A rough plan (still work in progress) is outlined on the wiki. The first step is to create an inventory of all documentation resources regarding l10n, across wikis, blogs and other documents. What we need is a flexible tool to create a collection of documents and describe them with tags. After some research I came to the conclusion that the best tool for this purpose is Delicious.com. It offers powerful tagging features (like bulk editing tags or creating tag bundles) and allows to export the collected bookmarks to a well-structured HTML file, which will, for example, make it easy (with some basic parsing) to create a graph of all resources that we know of (if we decide we need one). Delicious has also managed to create a thriving community of tools developers who take advantage of Delicious API to create stunning visualizations of relationships between bookmarks or tags (or both). I’m really looking forward to exploring some of the possibilities this will give us and see how we can use them in order to understand and improve our documentation.

And so I have created a Delicious account called “mozdocs“. I would like to use delicious’ tagging capabilities to create a list of documentation articles with tags describing the contents as well as the metadata, like the location of the article (I used the “at” syntax for this, i.e. @wikimo, @mdc, @blog, etc.). Just go to mozdocs’ bookmarks page on Delicious to see those tags in action. I’ll bookmark this very blog post, too, once it’s published, and tag it with “@blog, @stas, documentation.”

Delicous being a social network, it also offers a couple of neat networking features. You can add any account to your network and then post bookmarks for such defined contacts. In other words, you can add “mozdocs” to your network and then use the “for:mozdocs” tag to make the bookmark show up in mozdocs’s inbox!

If you feel like participating in this grand l10n documentation overhaul, I would like to ask you to bookmark any pages that in your opinion contain useful l10n documentation content and tag them with “for:mozdocs”. It doesn’t matter if you think that the page is so obvious that someone else must have already added it. Delicious is smart about detecting duplicates, and even if it wasn’t, I’d rather deal with duplicates than miss an important piece of documentation.

You don’t have to add any tags, but it will certainly help us if you do (and don’t hesitate to add a lot of them!) Also, if you see that an article is out-of-date, please use the “fixme” tag. I’ll be watching this tag and I’ll make sure the articles tagged with it are updated.

Thanks in advance for your help. I’m looking forward to discovering new l10n documentation pages that I haven’t seen yet :) I’m positive that using Delicious will help us tremendously to categorize the articles and identify those that need to be updated or rewritten.

As always, please share your thoughts in the comments.

We’d like to use the same approach for Fennec. For each locale, we’ll look at the region’s market and try to choose search engines that offer best user experience and bring a lot of added value to Fennec. To facilitate the process of suggesting search engines and choosing a few of them for including in localized Fennec builds, I’d like to suggest the following guidelines for choosing search engines in Fennec.

I propose the following 4 categories of search engines for localizers’ consideration:

• General search
  • 1 global
• Reference search
  • 1 Wikipedia
  • 1 e-commerce (store preferred over auctions)
  • 1 other (optional, a dictionary or a word reference recommended)
• Local search
  (i.e., “around me” search; e.g. “find the nearest ATM”)
  • 1 (only if available in the region)
• Specific interest
  (extra category, use if no local or 2nd/3rd reference search available)
  • 1 (can be from different categories: e.g. entertainment (imdb, youtube, music search), price comparison, general search provider very popular in the region, etc)

Not all categories are required for every locale, in fact, some should be ignored if there are no good search engines available in the region. This applies primarily to the local search (C). If no local search service provider is available in the locale’s region, then we should not include this category at all. Instead, we could look for other interesting search services from other categories and include them under category D. For example, if there’s no local search engine in Germany, then instead of shipping a US-based local search engine with the “de” version of Fennec, we could look for a different type of search engine that would offer good experience and be relevant for German users.

The maximum is 6 search engines. However, if you have good candidates for categories A, B and C, you probably should leave D out, and stay at 4-5 plug-ins. Also, all locales should start with a global general search provider and Wikipedia, and not the en-US defaults. This makes the minimum number of plug-ins equal 2. To sum up:

Minimum: 2 (general search & Wikipedia)
Recommended: 4-5 (subset of A, B, C, D)
Maximum: 6 (A+B+C+D)

To help decide which search engines to choose for each category, I propose to use the following list of criteria, similar to what we use for all productization components across all Mozilla projects, augmented by the compatibility criterion:

• User experience
  • Mobile compatibility
  • Search quality
  • Clean and easy-to-use interface
• Relevancy
  • Popularity in the region
  • Usefulness for locale’s users

To provide some background on the choice of categories: you may wonder for example why I listed e-commerce under “reference”. My assumption is that searching in Fennec is mainly about acquiring information, less so about performing actions on-line (like buying a product). We can then use this information to perform actions off-line, for example take out some cash in the nearest ATM as located by the search engine. A mobile browser brings together two worlds: the off-line world in which we operate and the on-line one in which we acquire information. Consequently, I see e-commerce sites as great sources of information, answering questions like ‘Who wrote that book? What year was this film released? What’s the 4th track on this album?’ etc.

Following this line of thinking, I see two main objectives for the search plug-ins from the user’s perspective:

1. acquire general information, knowledge, definitions, and
2. acquire location-specific information.

A third objective, this time from Mozilla’s point of view, is to demonstrate the feature called “adding search engine plug-ins to the chrome”. It could be argued that including more search engine plug-ins than Fennec’s search bar can fit would have an advantage of demonstrating the horizontal swipe-ability of the bar. On the other hand, offering less engines by default has two additional advantages:

1. There’s an empty space on the right of the bar (cleaner interface), possibly encouraging the user to fill it, by adding new plug-ins.
2. The first plug-in the user adds by herself will be visible right away on the search bar (it won’t be hidden) which, as I believe, will be more rewarding for the user and will make it easier to understand what has just happened (no questions like “Where is this search plug-in I just installed?”).

These reasons are convincing to me. I also believe that it is important to keep the interface clean. Contrary to Firefox, search plug-ins are a highly visible piece of UI in Fennec, somewhat similar to the bookmarks toolbar in a desktop browser. It is therefore crucial to find the right balance between offering more functionality with more search engines and keeping the interface clean and uncluttered. Let’s remember that the browser (together with the search bar) belongs to the user.

Please share your thoughts in the comments.

Today, let’s discuss the compatibility criterion, which I believe is the most important guideline for localizers to consider.

The compatibility criterion: Services included in Fennec must render correctly on mobile devices, assuring good readability and ease of interaction.

The compatibility criterion is important, because it allows us to base on Firefox’s guidelines and adapt them to the mobile context. In other words, Fennec’s productization should follow Firefox’s guidelines, making exceptions when the compatibilty criterion is not met.

As you probably remember, there are 5 productization components in Firefox, mapping to components in Fennec (in fact, the future of the live bookmark and the getting started page in Fennec is uncertain, but let’s just assume for now that they’re in):

1. Content handlers (a.k.a feed readers)
2. Protocol handlers (currently: webcal, mailto, irc)
3. Search engines
4. News feed (a.k.a. Live Bookmark)
5. The ‘Getting Started’ page

Fennec should ship only with services that meet the compatibility criterion. We should not promote websites that render badly on mobile devices, are impossible to read (e.g. because of the broken layout not adapted to the small screen), or impossible to interact with on mobile devices.

The good news is that I don’t expect there are many websites that don’t conform to this guideline. After all, Fennec’s developers have gone to great lengths to make sure the browsing experience is as good as on a desktop browser. You can pan and zoom easily, increasing the text size and focusing on chosen part of the website.

But I can imagine a couple of scenarios effectively breaking the mobile user experience, for example:

• a Flash-based ad covering a significant area of the website which is difficult to close/discard (due to very small close button),
• a non-standard input element with no accessibility fallback, which makes typing text into it difficult or impossible,
• websites detecting a small-screen device (which as a practice is not bad) and offering a broken layout.

I’m sure you can think of more example like these. Feel free to add them in the comments.

Mozilla’s mission ensures that the Internet, desktop and mobile alike, evolves in the  correct direction. In this context, that means open, participatory, and innovative. Good for the users. With Fennec, we’re becoming reponsible for building mobile Web the right way. We have the momentum and power to make an impact and make sure web designers and developers don’t ignore mobile in their projects. Because with no doubt, mobile will become one of the most important contexts of using Web, independently of region or demographics. Even more so, mobile is gaining a lot of traction in developing countries, which skip directly to the age of personal and portable computing. I like to think that we’re responsible for the direction in which the mobile Web evolves: open, participatory, and innovative.

Please add your thoughts. Is this criterion too strict? Too vague? Just right?

* * *

In the next post I’ll try to summarize my thinking about the search engines in particular and suggest a couple of categories of search engines that we might want to ship Fennec with.

In the last post I announced a short series about productization of Fennec. This is the second post in the series.

Before we actually start talking about the default services and best choices, we should provide some background on why’s and what-for’s.

There are two main purposes of adding default web services to Mozilla products:

1. provide users with useful and relevant content, and
2. demonstrate certain features of the product.

The first one (provide users with useful and relevant content) is obvious: we want to improve our users’ experience on the Web, so we provide a couple of well-thought suggestions for different services. For example, we ship Firefox with 6 or 7 search engine plug-ins to make users’ lives easier when they’re looking for information, translation, products, multimedia, spelling and definitions etc. Another example: when the user clicks on a mailto: link, we suggest a couple of possible handlers chosen from the applications installed on their computer. But we also suggest a few web-based clients (in en-US these are Yahoo! Mail and GMail right now, Hotmail’s coming), so that if the user happens to use one of these in the browser, they don’t have to configure them.

The second purpose (demonstrate certain features of the product) is equally important: by providing these default services, we demonstrate particular features of the product, the ones which otherwise wouldn’t be as discoverable. For example, putting one sample news feed on the Bookmarks Toolbar in new profiles in Firefox helps in learning about the Live Bookmarks. Including a couple of search engines instead of one in the Search Toolbar can help users understand that they can add as many plug-in as they wish. Also the Getting Started page in Firefox was created with this goal in mind: to show users how to get the most out of Firefox and the Web in general.

Overall, in Firefox, the productization includes five areas:

1. A news feed (a.k.a. Live Bookmark),
2. News readers,
3. Protocol handlers (currently: webcal, mailto; irc coming soon),
4. Search engines,
5. The ‘Getting Started’ page.

We’re still no entirely sure what the list would be for Fennec, so for now, let’s focus on these 5 areas.

The guidelines for productization of Firefox can be found on the wikimo. Let me quote an important passage from that page:

We believe that localization teams are in the best position to provide recommendations on what local providers we can use for Web Services because you’re in the market, work in the language, and know your users.

The same thing is true for Fennec, or any other product for that matter. The guidelines that we are working on right now are supposed to offer helpful suggestions, evaluation criteria and rules for choosing default web services for your locale. Your feedback on these guideline will be greatly appreciated, because after all, you as localizers will be making suggestions for productization of Fennec is your locale.

The notion of the mobile context spans both the hardware and the situation in which the user operates. These are very different from what we observe and know from the desktop experience and Firefox. To name just a few key differences:

• screen: much smaller on mobile devices,
• user control and input: touchscreen, on-screen keyboard, finger instead of the mouse cursor,
• use cases: for example, quick reference look-up, price comparison, closest restaurant or ATM (in these examples the browser is used for an ad-hoc and quick information retrieval).

Just as Firefox ships with a set of default search engines, content and protocol handlers etc., which are adapted to the needs of a desktop user, so will Fennec. The ensemble of these settings is called the ‘productization’. The important thing regarding the web services that make up for the productization of Mozilla software is that they are often specific to a local market. For example, a search provider can deliver a very good quality of search results — but only in a specific country or language, and we have to take this into account when considering default search engines for a locale. This brings us to the need of customizing the set of default web services on a per-locale basis, in order to ensure a good user experience across all locales.

In a couple of next posts on this blog I will try to describe which factors should be, in my opinion, considered important when choosing default services for localized versions of Fennec. The series is intended as a discussion starter and I would like the guidelines laid out in it serve as a base for a conversation about the localization-related needs and issues with Fennec’s productization. As Fennec is still under development, all people involved in the localization process can make an important contribution to the project by bringing to our attention specific needs of their locale.

• Estonian (et)
• Kannada (kn)
• Telugu (te)

Congratulations to the localization teams that made it possible!

Seth already did two great posts about our process: So what does “getting new languages ready for release” actually mean? and Moving a locale out of beta, but I thought I’d give some more detail on how the process fits into our code freeze and release schedule.

When we first add a new localization to the tree, it’s in its pre-beta status (let’s call it alpha). This happens after an initial review of the localization by Gandalf or Pike (the review includes checking if the directory structure is correct, the encoding is OK, if all entities are used correctly etc.), at which point a flock of new bugs is filed by the l10n-drivers team, as described on the wiki. These are things like creating a new Bugzilla component for the locale, landing the localization in its brand new repository or modifying the all-locales file for each branch that’s ready. The locale’s nightly builds start to build.

Localizers then continue working on the translation, pushing changes to the repository. At this point the productization and the web parts processes start. The guidelines and the description of the productization process can be found on the wiki. Two bits of the productization process are given special priority at this point: search engine plug-ins setup and protocol handlers setup (e.g. web-based mailto: handlers). We try to find a good and final list of both of this productization bits before the first beta release of the locale, or, if deciding on the final list is not possible straight away, we try at least to only include search engines and protocol handlers that we are sure are final. This is due to the fact that changing them later in the process is hard: once a user installs a beta release, their profile is created with these settings and removing search engines and protocol handlers from the profile gets tricky. For these reason search engines and protocol handler setup are both called ‘beta blockers.’

When the localization reaches a level at which it’s ready to be reviewed by the community, it is given the beta status and is listed on Mozilla.com website under ‘beta locales.’ This is done by modifying the shipped-locales file, which should happen before a code freeze for the next release. (Technically, the changes to shipped-locales are NPOTB, which stands for Not part of the build, so it is possible to land them after the code freeze, but is not preferred.) We also need to modify the product-details files which manage which versions are offered to download on Mozilla.com (e.g. on the all.html page). This is done by the WebDev team and the bug needs to be filed a couple of days before the release.

At this stage we can start gathering feedback from the users testing the release. Feedback can be anything: spelling or grammar mistakes, better wording suggestions, font rendering issues, dialog sizes, better suggestions for productization (this is why deciding on the final list in the previous step is preferred –  it allows us to gather feedback on productization from users too) etc. This is a very important stage and the feedback that the localizers get from beta users helps improving the quality of the final release.

All fixes to the issues reported by the testers need to be landed in a timely manner before a code freeze. A couple of simple rules should be followed:

1. Changes to translation on the development branches can be landed freely.
2. Changes to productization on the developement branches additionally require a review (r+) before they can be landed.
3. On stable branches, all changes to localization (translation and productization) should be reviewed and approved by the l10n-drivers team.

For example for the 3.0.x branch, if a localizer wishes to modify the translation (e.g. fix a typo), we ask them to file a bug and request a review of the patch. The reason for this is that we want to make sure that 3.0.x builds are green at all times (in case of an emergency in which a ultra-quick build is required to address a security hole, for example). Hence the review&approval process for all l10n changes on the 3.0.x branch.

While the locale is in beta, we also continue to work on productization and web parts. If not chosen before the beta release, we can now choose a news feed that will be featured on the bookmarks toolbar as the live bookmark or select a couple of good and popular news readers that will be offered to the user when they wish to subscribe to a feed. We also focus on the Getting Started page and other web parts, managed by Pascal. Since the web parts are served from the Mozilla.com servers, no changes to the l10n code are required to publish them. Consequently, it is possible to work on them even after the code freeze.

During all this time, the l10n-drivers team meet at least once a week for a so called triage call (Tuesdays at 6 PM CET / 9 AM PST) when we monitor and discuss the progress of the de-beta-ing process. We go through open blocker bugs for each locale and update a wiki page on which we track the whole process (for 3.0.x that’s Triage:3.0.x). From time to time we e-mail the localizers to discuss next steps, ask about the current feedback and offer help. We’d like to do a good job in this field, so if you are a localizer of a beta locale, please give us your feedback on how we did in the comments below, by e-mail or via Rypple (it’s completely anonymous).

If statistics are available, we look at the usages figures (ADU numbers and downloads) to see if they are increasing. This is a good indicator that end-users are, at least generally, satisfied with what is available.  Finally, when the localizers feel good about their work, there are no more open blocker bugs, the feedback from the users is positive and the testing of the builds under all three platforms hasn’t showed any rendering/display/sizing/other issues, the decision to move the locale is taken. A couple of days before the release the product-details files are changed again to make sure that the locale will be listed as final, not beta (for 3.0.7 the bug for this was bug 480391). The release notes are changed accordingly. And when the release day comes, we party :)

UPDATE: Originally we also intended to de-beta Occitan (oc), which was on the list above, but it turned out that bug 454169 was still open. Stay tunned for 3.0.8! :)

Take the survey now.

We all know the localization process is much more than translation. As much as it consists of actually translating the strings that you see in the product’s interface, it also involves lots of other activities, such as adapting the product to the need of the local users (think default search plug-in for example), making sure the first-run experience is good for the local users (web parts: the firstrun page, the ‘Getting started’ page etc.), and that the software update process will also be available in the user’s language. It also involves a fair share of testing and quality assurance, to make sure everything is in place the day of the release.

During all the years of active work, many localization teams have worked out their own practices and procedures regarding testing. We called them “testing plans”. Now, you may think that this is too much of a word in some cases, but we like to think that even a short list of things to check (e.g. accesskeys) before the release is, in fact, a simple testing plan. And it is equally interesting to see what items are included in such a list, as well as how the list itself is stored, presented and maintained (litmus, wiki, google doc and  many other possibilities).

So it’s natural that when Mozilla starts thinking about localization testing plans, we first look at what’s been already invented and proved to work well. There are many localization teams, each with their own way to test the localization, suited for their needs and resulting from their approach and past experience. What if we could share these practices between the localization teams  and help other teams adopt them?

The above briefly summarizes the discussion we had on the objectives of the survey. If you would like to help us, please take the survey! :)

It consists of 20 questions, split into four sections:

• Section 1. Tell us about you and your team
• Section 2. Test Cases, Testing Coverage and Planning
• Section 3. How can Mozilla help?
• Section 4. May we contact you?

It should take about 10 minutes to complete. Thanks!

Mamy więc niesłychanie aktywne forum oraz centrum pomocy na stronach MozillaPL, mamy polskie SUMO, czyli support.mozilla.com – oficjalne strony pomocy dla Firefoksa, a w nieco dalszej perspektywie – dla wszystkich produktów Mozilli. Po polsku jest też strona z dodatkami dla Firefoksa i po polsku także będą takie strony, jak “pierwsze kroki”, które pomogą użytkownikom (nie tylko nowym!) poznać Firefoksa 3.

Cały ten wysiłek jest uzasadniony czymś, co dla nas stanowi niewyobrażalną motywację. W niewielu innych krajach Europy Firefox jest tak popularny jak w Polsce (prawie 36%!). Nasi użytkownicy nie dali o sobie zapomnieć także podczas trwających właśnie przygotowań do Dnia Pobierania, kiedy to wszyscy razem spróbujemy pobić rekord Guinnessa w liczbie pobrań programu komputerowego w ciągu 24 godzin. Polska od samego początku utrzymuje się na 2. pozycji, a wyprzedzają nas tylko Stany Zjednoczone (Brazylia depcze zaś po piętach).

Wracając do tłumaczeń i stron: właśnie na SUMO chciałbym skupić nieco więcej uwagi. Polskim SUMO opiekuje się Marek Wawoczny, sam założyciel MozilliPL. Mimo ogromnego wysiłku, jaki Marek włożył już w tłumaczenie SUMO, wciąż można nam pomóc, do czego serdecznie zachęcam i do czego nawiązuje tytuł posta.

Otóż w tę niedzielę zakończy się organizowany przez Mozillę konkurs mający na celu przygotowanie screencastów ilustrujących artykuły SUMO. Pisemne instrukcje są dobre, ale jak wszyscy wiemy, nic nie działa tak dobrze, jak prowadzący za rekę film z wyjaśnieniami (no, może prowadzący za rękę znajomy).

Aby wziąć udział w konkursie, wystarczy wybrać jeden z artykułów Top 100 SUMO i przygotować krótki film pokazujący wykonywanie instrukcji z artykułu. Do tworzenia screencastów można użyć polecanego przez Mozillę programu Jing (działa pod Windows i Mac OS X). David Tenser, opiekun SUMO, poprosił wczoraj na swoim blogu, by w miarę możliwości skupiać się na 6 podanych przez niego artykułach, które wciaż czekają na swoje screencasty.

Oczywiście, jak to na konkurs przystało, przewidziano nagrody :)

Po więcej informacji o samym konkursie odsyłam na stronę mu poświęconą, poniżej zaś, w ramach zachęty i pokazania, że da się i że zajmuje to mniej niż godzinę, dwa screencasty które przygotowałem dla artykułu Backing up your information.

Backing up your profile

Restoring a profile backup

A zatem pomysł dla ponad 80 tysięcy Polaków, którzy zapisali się na Dzień Pobierania: jeśli macie godzinę w ten weekend, podczas której chcecie pomóc nam tuż przed wydaniem Firefoksa 3, weźcie udział w konkursie! :-) A jeśli wolicie pracę z tekstem, to zapraszam do pomocy przy tłumaczeniu i korekcie – wystarczy e-mail do Marka na adres: mwawoczny w domenie aviary.pl.