Hi All, Friedel has shown me these pages before but I think this is the first time I've looked hard at it. Even when opened in a text editor with highlighting I found it hard to work out what to translate. I have another suggestion for an approach to simplify this. I realise that having the page working as is and readable is probably quite important. My suggestion is that we put all the localisations at the top of the page as PHP variables and then use those variables in the actual page content. That way all the items that need localisation are in one place. The added benefit is that the Translate Toolkit already has a php2po tool that could extract those items that need localisation and pump them back. Clean and simple yet still workable for whoever is testing the page. Just an idea that I'll leave with you guys. Should this be discussed in a bug?
To elaborate on the ideas in comment 1. I'm not a PHP developer so I don't know about scope of variables etc. But here is a snippet to convey the general feeling of what I'm proposing, its pulled from the link Fridel gave, but simplified. <? l[page_title] = 'Firefox web browser | Help us test the latest beta'; l[main-feature-heading] = 'Help test the future of Firefox!'; ?> <?php // The $body_* variables are for compatibility with pre-existing css $page_title = $l[page_title]; ?> <div id="main-feature"> <h2><?$l[main-feature-heading]?></h2> </div> ----------------- As I said I don't code PHP so I'm not sure what happens to everything here.
You're ignoring that our web parts don't consist of just translation. Btw, linking to empty blog posts is just not constructive.
(In reply to comment #3) > You're ignoring that our web parts don't consist of just translation. I'm having to guess what you mean here. Do you mean that some teams need to customise these pages or fix things? If that is so it still does not change the case for the majority of teams who don't need to customise or fix anything, they just need to translate. I think my suggestion in comment 2: 1) Allows both translation and customisation to be achieved together 2) Keeps the page and the translations together for easier debugging 3) Most importantly, makes translation easy since all translatable text is at the top of the file (so you know what to translate) and follows PHP escaping (so there is only one type of escaping). I think its a workable solution. What do you think? > Btw, linking to empty blog posts is just not constructive. ??
(In reply to comment #4) > If that is so it still does not change the case for the majority of teams who > don't need to customise or fix anything, they just need to translate. > > I think my suggestion in comment 2: > 1) Allows both translation and customisation to be achieved together > 2) Keeps the page and the translations together for easier debugging > 3) Most importantly, makes translation easy since all translatable text is at > the top of the file (so you know what to translate) and follows PHP escaping > (so there is only one type of escaping). I would like to see someone from Mozilla respond directly to Dwayne's suggestion. If we are going to make any progress, we should stay on point in this bug and respond to points. If there are links to other bugs where we have previously discussed this, please link them. If not, for documentations sake, can we respond in this bug? > > Btw, linking to empty blog posts is just not constructive. > > ?? Please stay on point in this bug. All I want to see is a reason why we can or cannot make progress. If we are going to cut and paste emails, please make sure all links are relevant to the bug. In comment 1, I followed a link that looked like a default signature to Friedel's email, giving brief thoughts about monoligual file formats. Is this bug about simplifying Mozilla's web-l10n or monolingual translation formats or both? Please clarify because the link there is confusing to me.
(In reply to comment #5) > In comment 1, I followed a link that looked like a default signature to > Friedel's email, giving brief thoughts about monoligual file formats. > > Is this bug about simplifying Mozilla's web-l10n or monolingual translation > formats or both? Please clarify because the link there is confusing to me. OK know I understand. My fault, I just did a Ctrl-A, Ctrl-V when pasting Friedel's mail into the bug. I think Friedel's email was clear on the purpose. But if it helps clarify things this is about web-l10n and making the localisation of it easier its not about monolingual files.
Ah, OK. I have raised the question in our internal discussions before, and yes, the current way we do our webpages makes us hit the limits in how many locales we can take and release. We need to come up with something better, definitely. I don't think that multilingual files are going to be an option, as we need to support the addition and removal of content. I'm not sure just yet on how much we need the ability to tweak the living shit out of our HTML, especially for particularly verbose languages or RTL languages. I'm neither sure if the same answer holds true for our start page snippets as for the majority of our web pages as for getting started (which is really the only page with localized content). My personal feeling is to restrict ourselves to some kind of wiki markup for which we can create good UI/UE for the common parts would be the way to go, but that's just my personal "I can mediawiki fast" way of thinking. We're going to have an intern over the summer that did some UI on placables, Jeremy. I'm looking forward to discuss with the group including him on how we can present HTML such that it's hard to get wrong, and still easy to get right. And, for Pascal and Stas, easy to confirm it's right.
It's been a year since the last comment in this bug, I'll take the liberty to summarize, and close. Doing l10n should always become easier, and there are multiple angles in which we're currently working. There's pontoon in the works to localize web pages inline, which I guess would fit the initial comment. Best described at http://diary.braniecki.net/2010/04/19/pontoon-introduction/, I guess. We've got verbatim up for quite a few web properties, too. The webdashboard got better. While the majority of our in-product web pages are still plain html, I expect those to migrate to new foundations as soon as they're stable, offer the right features (read, not just translation), and performant enough for the main mozilla.com site. I don't see keeping this bug open helping us. If there are pages with particularly hillarious php code still in them, or other pieces, I'd suggest to file bugs on those individual pages in Websites, mozilla.com component.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.