L10n Talk:MLP page structure

AxelHecht

The main reason why the current l10n pages are in such a cluttered state is that they don't precisely target a single audience. This is the hardest decision in setting up docs, anyway.

IMHO, the l10n pages should solely focus on l10n contributors. That is, just contain parts 2 and 4.

The localized builds don't belong into the l10n page, but on the product pages, or, for nightlies, on the project pages of the respective products (or products to be, for calendar).

The developer section is really intl, not l10n.

I suggest to add links to intl and the product pages at a few places, but don't get that content in there.

reply to Axel, by KaiRo

I still think we'll always have users visiting our pages, and we should give them some pointers. I don't think we want a whole set of user pages, as you're right, they don't belong there. A section/block on top of the main page with some pointers for users should help them though.

The same is true for what I intend for developers: have a block at the bottom of our front page, linking the most important stuff they could be looking for. If we might have some docs in our directories, we might link them there as well.

The biggest problem I see with what we currently have is that we have a big front page with lots of text and a few links spread in, so it's really hard to find any stuff from there. Additionally, we have no structure at all behind all the other docs on our pages, so even when we're adding something new, it's hard to find and we don't even really know where to put/link it in most cases. It's just stuff thrown into one directory in a complete mess without any reasonable structure. Even removing any stuff not directly targeted at localizers wouldn't really change that.

The main page should be reduced to short blurbs and mainly links, that's one other thing that will help a lot (and what I have intended to achieve here).

discussion from 2005-02-22 MLP staff meeting

This is a rough excerpt of our discussion about MLP pages, made by KaiRo - be warned: that transcript is far from complete!

<sskroeder> I would suggest a download-page per locale as well ...
<sskroeder> a "Go to this page for all danish Moz Products" idea...
<KaiRo> sskroeder: basically a good idea, and we should think through it... Though I guess we should remove the current download lists from our pages, as they only duplicate the products' own pages
<MadMaks_Laptop> KaiRo: except for the mozilla suite xpi's, the are not on the product page
<sskroeder> KaiRo: The only (and essential) difference is that a "da-DK-products" page will have the locale/Country as primary focus - instead of the individual product download pages, that have the product as a primary focus ...
<KaiRo> MadMaks_Laptop: we probably should put them up on the product pages as well
<MadMaks_Laptop> sskroeder: don't we have mozilla-europe for that
<sskroeder> Most localized downloads are due to the hype that Firefox has had --- unfortunately it's not -per default - obvious that MoFo also have other localized products in the same locale...
<sskroeder> MadMaks_Laptop: sure EuroMoz is used for that -- but outside the actual Moz Community, how many do you think go to MozEuropa when they hear of this fantasic new Firefox browser ..
<MadMaks_Laptop> sskroeder: true
<MadMaks_Laptop> so we can point from our site to them
<KaiRo> MadMaks_Laptop: though we must consider that there are languages outside europe and japan, which have no such pages
<MadMaks_Laptop> i think we provide a list whit the localizers and witch program are localized
<KaiRo> so we probably could be pointing to Mozilla Europe/Japan for languages where they have translations, and have our own pages where they don't exist.

Mark's thoughts on automatically built Downloads pages

(following on from the 2005-02-22 MLP-staff meeting)

NB: some (or more) of this may be stating the obvious...

• We want a single source of data.
• We want many pages, containing downloads for a specific locale (I could see either language or country being useful)
  • Do we want to restrict ourselves to stable products?
  • Do we want these pages to act as a historical repository?

The fields should be

 language	// [code]
 country	// [code]
 locale		// [proper name]
 program	// firefox|thunderbird|suite|sunbird
 version	// [number]
 platform	// win|linux|mac|none
 type		// langpack|zip|tar.gz|Installer|Mac Disc Image
 stable		// yes|no
 path		// should be computable from above info?
 (any others?)

Then a list on a per-locale page would be constructed by

SELECT * FROM downloads
WHERE language='ab' OR country='CD'
ORDER BY program, platform, type

(I'm expressing myself in database terms because that seems most natural, but it doesn't have to be implemented like that -- a CSV file would be fine, though it would mean more work on the parsing front)

Questions:

• Do we want to the data-source to be historical (storing all versions of all packages), or should only details of the latest version of each package be kept?
• Can we use the mozilla.org site's build to run our scripts?