1. EU Inter-Community Meetup Geneva, Saturday, 13 June, 2009

2. Reaching 100 locales ● 75 locales ready for Firefox 3.5. What's next? ● Which areas of the world are not covered? ● Identifying the locales ● Reaching new contributors ● The Mozilla localization process complexity ● Simplifying the process ● Webtools ● Contractor for the initial landing ● Other means? Reaching 100 locales ● 75 locales ready for Firefox 3.5. What's next? ● Which areas of the world are not covered? ● Identifying the locales ● Reaching new contributors ● The Mozilla localization process complexity ● Simplifying the process ● Webtools ● Contractor for the initial landing ● Other means? Reaching 100 locales ● 75 locales ready for Firefox 3.5. What's next? ● Which areas of the world are not covered? ● Identifying the locales ● Reaching new contributors ● The Mozilla localization process complexity ● Simplifying the process ● Webtools ● Contractor for the initial landing ● Other means?

3. Mozilla Developers Center ● Tables for layout ● Deki syntax ● Page history ● Most viewed pages ● Recent changes

4. KompoZer Localization ● The project roadmap and goals ● KompoZer is very popular and part of several distros ● Current locales: de, es-ES, en-US, fr, it, ru ● Tools: l10n hg repository, Narro, langpack script, import script from Mozilla repos ● Most current contributors are from outside the Mozilla community

5. == Tables for layout == The main page and several others use tables for layout. Everyone knows it is bad practice, and is somewhat ironic on a website dedicated to open standards. - The logo could be floated. - Columns could be made with CSS3 attributes (-moz, -opera, -webkit). The content would still "gracefully degrade" in IE. == Source syntax == First, as I said last year before the migration, I don't buy that syntax is HTML, XML or whatever known by the contributors. It is only a storage format which is transformed on the fly by the system to generate the actual HTML pages. Therefore, departing from a maybe not perfect but at least widely used wiki syntax was a bad idea. Anyway, since this format is also not backwards compatible to the MediaWiki syntax, I guess we have to live with it. There are several ways it could be improved though. For example, a typical link is of the form: Page title which, transformed by the system, becomes: Page title "https://developer.mozilla.org/lang/Page_title" Some questions arise: - Why do we have to repeat the same information (Page title) three times? Can't the title be implied from the last part of the href? Is the title attribute needed at all? - Why do we need to inform the system that the link is "internal"? Can't he know that from the pseudo-protocol prefix and the localhost part? - What the hell is rel="internal" in the generated code? The rel attribute "describes the relationship from the current document to the anchor specified by the href attribute" (HTML4). How is the linked page "internal" to the current page? - What about using relative URLs? Suggestion: Page title (same language) Page title (other language) All the extra cruft, if needed at all, can be generated on the fly by the parser for internal use. Just don't expose it to the editors and don't keep it in the source format for new links. Note: rel="internal" is neither accepted or even proposed for HTML5 http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#linkTypes http://wiki.whatwg.org/wiki/RelExtensions == Page history == The new presentation (side by side diff) is better, but still a long way to be usable. * no visible change when the target of a link is changed * when the formatting changes, we don't know what or where the change took place * a contextual diff instead of a full diff would be more practical == Recent changes == Recent changes used to be sortable by language, but the selector is not visible anymore (actually a regression since the last upgrade). == Most viewed pages == The most viewed pages sould be sortable by language, it would help us prioritize article translations and updates.

6. == Most wanted pages == We need to know which pages are the more badly needed, in terms of incoming links. * This feature should exist (MediaWiki parity) * Should be sortable by language == Interlang == We need reporting tools to fix interlang links, and some tasks could be automated. * Detect broken interlang links (following a rename) * Suggest missing interlang links (for example, when [en] links [fr] and [ja] but [fr] links [en] only) * Automatic fixing of interlang links (replicate the old japanese interlang bot behaviour) == Detect out of date translations == * Flag them? See what was done on support.mozilla.org * Help us prioritize translation by most wanted/most viewed/out of date pages == Other considerations == - The link “RSS feed” is useless in the current state in "Site tools". It displays a feed for each registered user. It would be great to have a feed by language for instance. - Deki syntax is awful and the source for a waste of time. Just take a look at the templates for instances. - The search for a link to translate and already existing on another page when localizing is not easy (that was the same with mediawiki). Deki doesn't offer much for this matter. The link update system could be used to identify its links with (anchors) - The link on the MDC banner is redireted to the home page, but always in English. It should link to the home page in the same language than the page previously visited.