Localization discussions

Is it a new policy to treat many locales differently to en-US

  • 7 Replies
  • Last reply by John99
  1. John99
    John99 3665 posts
    more options

    On the one hand I understand: Changes to the default search engine being a positive advantage to locales. A locale gets a better search engine.

    On the other they lose out. It is a disadvantage. Pocket was promoted as a great step forward but only given to some locales. Locals that missed out would see promotional material and resultant blogs but have no clear explanation of what was happening or why they had no pocket button.

    Now with Windows 10 a big global software release we are prioritising only some locales to explain how to keep Firefox as the default browser after their upgrade switches them to Edge the new Windows 10 browser. (Or does the Windows 10 release get delayed, or not switch the default browser ? <- I have not noticed talk of that)

    On the one hand I understand: Changes to the default search engine being a positive advantage to locales. A locale gets a better search engine. On the other they lose out. It is a disadvantage. Pocket was promoted as a great step forward but only given to some locales. Locals that missed out would see promotional material and resultant blogs but have no clear explanation of what was happening or why they had no pocket button. Now with '''Windows 10''' a big global software release we are prioritising only some locales to explain how to keep Firefox as the default browser '''after their upgrade switches them to Edge''' the new Windows 10 browser. (Or does the Windows 10 release get delayed, or not switch the default browser ? <- I have not noticed talk of that)
  2. vesper
    vesper 1182 posts
    more options

    Hello John,

    With l10n and SUMO, the general policy is to "localize everything into all possible locales, always, as much as possible".

    Some locales will definitely be more strategic and important for some updates, and that's why I would emphasize the need of localizing some articles to members of the communities that use those locales.

    How do you suggest we address limited launches like the Pocket one in the future, in SUMO content. Should the en-US source always include a paragraph included only for non-launch locales, explaining that the feature is available in a limited number of locales (like here)? Should there be some other way of highlighting that? Maybe we should hide support content for the temporarily excluded locales? (that last option doesn't sound good to me, but that's a personal opinion).

    Cheers,

    Michał

    Hello John, With l10n and SUMO, the general policy is to "localize everything into all possible locales, always, as much as possible". Some locales will definitely be more strategic and important for some updates, and that's why I would emphasize the need of localizing some articles to members of the communities that use those locales. How do you suggest we address limited launches like the Pocket one in the future, in SUMO content. Should the en-US source always include a paragraph included only for non-launch locales, explaining that the feature is available in a limited number of locales ([https://support.mozilla.org/en-US/kb/where-pocket-button-firefox like here])? Should there be some other way of highlighting that? Maybe we should hide support content for the temporarily excluded locales? (that last option doesn't sound good to me, but that's a personal opinion). Cheers, Michał
  3. John99
    John99 3665 posts
    more options

    Hi Michał,

    Let's give a bit of background before answering your questions.

    I suppose my main reason for posting this is that we seem to have a new Mozilla policy that Sumo needs to adapt to for both the KB side of things and the l10n.

    I believe our current & preexisting Sumo policies revolve around the expectations that

    1. Firefox will differ between versions:
      Improvements are made, new features added and problems are resolved and old features deprecated.
    2. Firefox will differ on different platforms and different devices.
      • Windows 10 may be an interesting dilemma
    3. Firefox is essentially the same on all locales, except for the localisation.

    The final point now appears to be false, but we do not appear to have taken this change into account. If so we need to recognise this and discuss how we need to evolve.

    1.) Firefox Versions. A critical change of policy was the rapid release cycle: 6 weeks. We have had to adapt to modifying articles or writing brand new ones for new Releases. We can do this rapidly now and probably cope fairly well. Having specific showfor's allows us to customise the articles so that the end users has the correct information, and usually is automatically presented with the correct version of the KB article.

    Another change ESR, that is probably to be considered permanent now, and may diverge from standard Releases. Currently it is not causing problems. I don't know whether by ESR fx44 it may be continuing, but diverging from Release fx44. We can cross that bridge when we come to it. We should have no Sumo issues as we get loads of notice about what is happening and can always add an additonal KB showfor if necessary.

    We will be likely to struggle if a change is made without riding the trains, especially if it is released mid release as a point release. Writers editors and reviewers need time to finalise articles and make them Ready For Localisation (RFL). Ideally locales see the final article in advance and localise it once.

    Having to push at short notice as RFL and needing urgent localistion, followed by likely revisions and repeated localisation is bad.

    2.) Platforms & Devices This is a problem needing review at Sumo level but probably not too important for l10n discussion other than the OS specific changes. Currently Fx OS & Fx Android largely have there own articles. OS version differences are coped with by the KB showfor. Windows 10 Not a L10N issue at present. May be worth thinking and in advance asking ourselves at Sumo how will we cope with Windows 10 as it changes. Presumably already we will be needing to think about how its to touch screen capability, affects our KB articles.

    At a future date how will we cope with Windows 10 changes. Even if it is branded as Windows 10 we are going to have to somehow deal with Windows 10 2015|2016|2017 and I presume some changes will affect Firefox & our KB articles.

    3. Locales With the differences building up I think we need to think about this. The primary question is: Is this a new policy and likely to continue ? My supposition is YES it is a new policy, and YES it is likely to continue, possibly with many such changes not riding the trains, and so causing headaches !! at Sumo IIRC no one has really announced this as a new policy. We are de facto getting more and more locale specific changes. The next one I am aware of is the new tabs page will be changing in a locale specific way.

    This is getting long. I will continue in a separate post.

    Hi Michał, Let's give a bit of background before answering your questions. I suppose my main reason for posting this is that we seem to have a new Mozilla policy that Sumo needs to adapt to for both the KB side of things and the l10n. I believe our current & preexisting Sumo policies revolve around the expectations that # Firefox will differ between versions:<br /> Improvements are made, new features added and problems are resolved and old features deprecated. # Firefox will differ on different platforms and different devices. #* Windows 10 may be an interesting dilemma # Firefox is essentially the same on all locales, except for the localisation. The final point now appears to be false, but we do not appear to have taken this change into account. If so we need to recognise this and discuss how we need to evolve. '''1.) Firefox Versions.''' A critical change of policy was the rapid release cycle: 6 weeks. We have had to adapt to modifying articles or writing brand new ones for new Releases. We can do this rapidly now and probably cope fairly well. Having specific showfor's allows us to customise the articles so that the end users has the correct information, and usually is automatically presented with the correct version of the KB article. Another change ESR, that is probably to be considered permanent now, and may diverge from standard Releases. Currently it is not causing problems. I don't know whether by ESR fx44 it may be continuing, but diverging from Release fx44. We can cross that bridge when we come to it. We should have no Sumo issues as we get loads of notice about what is happening and can always add an additonal KB showfor if necessary. We will be likely to struggle if a change is made without riding the trains, especially if it is released mid release as a point release. Writers editors and reviewers need time to finalise articles and make them Ready For Localisation (RFL). Ideally locales see the final article in advance and localise it once. Having to push at '''short notice as RFL''' and needing urgent localistion, followed by likely revisions and repeated localisation is bad. '''2.) Platforms & Devices''' This is a problem needing review at Sumo level but probably not too important for l10n discussion other than the OS specific changes. Currently Fx OS & Fx Android largely have there own articles. OS version differences are coped with by the KB showfor. ''' Windows 10 ''' '''Not a L10N issue''' at present. May be worth thinking and in advance asking ourselves at Sumo how will we cope with Windows 10 as it changes. Presumably already we will be needing to think about how its to touch screen capability, affects our KB articles. At a future date how will we cope with Windows 10 changes. Even if it is branded as Windows 10 we are going to have to somehow deal with Windows 10 2015|2016|2017 and I presume some changes will affect Firefox & our KB articles. '''3. Locales''' With the differences building up I think we need to think about this. The primary question is: '''Is this a new policy and likely to continue ?''' My supposition is YES it is a new policy, and YES it is likely to continue, possibly with many such changes not riding the trains, and so causing headaches !! at Sumo IIRC no one has really announced this as a new policy. We are de facto getting more and more locale specific changes. The next one I am aware of is the new tabs page will be changing in a locale specific way. This is getting long. I will continue in a separate post.
  4. John99
    John99 3665 posts
    more options

    vesper said

    Hello John, With l10n and SUMO, the general policy is to "localize everything into all possible locales, always, as much as possible". Some locales will definitely be more strategic and important for some updates, and that's why I would emphasize the need of localizing some articles to members of the communities that use those locales.

    I realise that is the policy, and that some locales are able to localise a greater amount of the KB than others. Largely what is locaclised may be based on an article's viewing rating. That is not applicable to new articles.

    • Do we need some new RFL flag ? Urfl for Urgent RFL articles.
      Possibly to cover articles
      1. That would already be considered important when editing, despite their rating, or absence of a rating. That includes articles linked from the UI or platform articles.
      2. Because the locale will see a change.
      3. Because the locale will notice a campaign with resultant publicity and information in web searches but will not see the new feature.
    How do you suggest we address limited launches like the Pocket one in the future, in SUMO content. Should the en-US source always include a paragraph included only for non-launch locales, explaining that the feature is available in a limited number of locales (like here)?

    Besides recognising this is sort of problem is going to keep happening, it would help to keep everyone informed of progress, and get out information as far in advance as possible.

    • Does Sumo agree that changes at short notice cause problems with KB writing and localisation ?

    Gerv pointed out over 1/2 of sumo users worldwide did not get the pocket improvement. The pocket improvements indirectly caused the axing of a popular working Firefox addon for those people.

    The sumo blog recently linked to a KB bug so we could be kept informed, only for that and related KB bugs to be hidden from us.

    Should there be some other way of highlighting that? Maybe we should hide support content for the temporarily excluded locales? (that last option doesn't sound good to me, but that's a personal opinion). Cheers, Michał

    Presuming we know what is happening.

    • As a minimum we probably need a new showfor en-US so that we can write articles properly.
    • Better still could we consider a finer grained approach
      Specific showfors for all locales in much the same way it works for Windows and windows versions
    • Really need to solve the issue how about involving sumodev and asking for proposals. Maybe some sort of editable lookup table of features and what locale they apply to.

    Then we may write articles for locales with and without the feature and ensure end users and l10n see correct content.

    ''vesper [[#post-66266|said]]'' <blockquote> Hello John, With l10n and SUMO, the general policy is to "localize everything into all possible locales, always, as much as possible". Some locales will definitely be more strategic and important for some updates, and that's why I would emphasize the need of localizing some articles to members of the communities that use those locales. </blockquote> I realise that is the policy, and that some locales are able to localise a greater amount of the KB than others. Largely what is locaclised may be based on an article's viewing rating. That is not applicable to new articles. *'''Do we need some new RFL flag ?''' Urfl for Urgent RFL articles. <br /> Possibly to cover articles *# That would already be considered '''important''' when editing, despite their rating, or absence of a rating. That includes articles linked from the UI or platform articles. *# Because the locale will '''see a change'''. *# Because the locale will notice a '''campaign''' with resultant publicity and information in web searches but will '''not see''' the new feature. <blockquote> How do you suggest we address limited launches like the Pocket one in the future, in SUMO content. Should the en-US source always include a paragraph included only for non-launch locales, explaining that the feature is available in a limited number of locales ([https://support.mozilla.org/en-US/kb/where-pocket-button-firefox like here])? </blockquote> Besides recognising this is sort of problem is going to keep happening, it would help to keep everyone informed of progress, and get out information as far in advance as possible. *Does Sumo agree that changes at short notice cause problems with KB writing and localisation ? Gerv pointed out over 1/2 of sumo users worldwide did not get the pocket improvement. The pocket improvements indirectly caused the axing of a popular working Firefox addon for those people. The sumo blog recently linked to a KB bug so we could be kept informed, only for that and related KB bugs to be hidden from us. <blockquote>Should there be some other way of highlighting that? Maybe we should hide support content for the temporarily excluded locales? (that last option doesn't sound good to me, but that's a personal opinion). Cheers, Michał </blockquote> Presuming we know what is happening. * As a minimum we probably need a new '''showfor en-US''' so that we can write articles properly. * Better still could we consider a finer grained approach <br /> Specific showfors for all locales in much the same way it works for Windows and windows versions *Really need to solve the issue how about involving sumodev and asking for proposals. Maybe some sort of editable lookup table of features and what locale they apply to. Then we may write articles for locales with and without the feature and ensure end users and l10n see correct content.
  5. vesper
    vesper 1182 posts
    more options
    John99 said
    Presuming we know what is happening.
    • As a minimum we probably need a new showfor en-US so that we can write articles properly.
    • Better still could we consider a finer grained approach
      Specific showfors for all locales in much the same way it works for Windows and windows versions
    • Really need to solve the issue how about involving sumodev and asking for proposals. Maybe some sort of editable lookup table of features and what locale they apply to.
    Then we may write articles for locales with and without the feature and ensure end users and l10n see correct content.

    Thanks for your comments, John.

    New articles are indeed a slightly different issue.

    We already have a "show for" all SUMO locales built in, actually - it's the locale switcher ;-)

    I think we can use the existing HTML comments in articles to inform localizers whether a section should be localized or not. This will save dev time for putting another "show for" condition.

    The good thing about the KB is that nowhere does it say that en-US articles have to be localized 1:1 into all the other locales - there can (and in some cases should, as we can see) discrepancies. I will talk to Joni about figuring out a best way of ensuring localizers can easily see what should and should not be localized for their locale when they get into the article localization view.

    Cheers,

    Michał

    added blockquote tag ~J99

    ''John99 [[#post-66268|said]]'' <blockquote> Presuming we know what is happening. * As a minimum we probably need a new '''showfor en-US''' so that we can write articles properly. * Better still could we consider a finer grained approach <br /> Specific showfors for all locales in much the same way it works for Windows and windows versions *Really need to solve the issue how about involving sumodev and asking for proposals. Maybe some sort of editable lookup table of features and what locale they apply to. Then we may write articles for locales with and without the feature and ensure end users and l10n see correct content. </blockquote> Thanks for your comments, John. New articles are indeed a slightly different issue. We already have a "show for" all SUMO locales built in, actually - it's the locale switcher ;-) I think we can use the existing HTML comments in articles to inform localizers whether a section should be localized or not. This will save dev time for putting another "show for" condition. The good thing about the KB is that nowhere does it say that en-US articles have to be localized 1:1 into all the other locales - there can (and in some cases should, as we can see) discrepancies. I will talk to Joni about figuring out a best way of ensuring localizers can easily see what should and should not be localized for their locale when they get into the article localization view. Cheers, Michał ----- <sub> added blockquote tag ~J99

    Modified by John99 on

  6. John99
    John99 3665 posts
    more options

    Thanks Michał Yes I understand the locale switcher ;-) I just do not think repeated, late, ad-hoc comments are the way forward with this change of policy. It will be interesting to hear Joni's comments as hopefully a proper plan is being proposed to deal with this situation.

    FORUM INSTRUCTIONS You appear to favour going for a complicated manual method of explaining points to multiple individual locales. Such a method then probably buries information in this forum away from the article itself. That may be ok as a method of communicating with locales, but it is pretty bad as a method of writing, discussing & editing articles.

    If locales each write their own articles who reviews those ?? The articles are no longer l10n needing only to be reviewed with respect to l10n they are new or at least important revisions. At the very least we need some formalised method of flagging and reviewing such articles.

    KB INLINE INSTRUCTION & CONTENT All we really need is a to write the original article to cover

    • Feature present
    • And feature absent,
      • Or feature modified.

    What I am saying is we should do this. Of course we need to know it is necessary. So we need to be kept informed about what is happening. Assuming trends continue we will repeatedly have this issue. Resorting to peppering articles with l10n remarks, and remmed out sections seems clumsy, confusing, and hard to maintain.

    What if any method do we have for

    • Sumo being notified
    • Individal l10n people being notified

    When either a feature changes or does not chage, i.e. the locale is forked ?

    RESEARCH & PREPARATION Someone in Rel Eng will know exactly what change goes in what locale, let's face it the code has to be changed or not. We could at a minimum add the information to the article discussion tab to say which locales have or do not have a feature. We should then write the article accordingly. What I suggest is we consider better methods than having to litter articles with l10n notes and preferably get this automated.

    We need to cope with the following because of locale forking:

    • Feature may be present | Absent |modified
    • End users look at articles that have not been localised.
    • Automate RFL for important changes|forking
      • Locales need to be aware which articles are important
      • Locales need to be aware whether they are forked or not
    The good thing about the KB is that nowhere does it say that en-US articles have to be localized 1:1 into all the other locales - there can (and in some cases should, as we can see) discrepancies. I will talk to Joni about figuring out a best way of ensuring localizers can easily see what should and should not be localized for their locale when they get into the article localization view. my emphasis ~J99

    I consider we need to deal with the discrepancies when writing or modifying the article. We do not want locales reinventing the wheel and each writing their own article or version of an article. We want to make it easy for locales and have them localise parent article from en-US. If en-US writers & reviewers have difficulty figuring out what is happening it is unreasonable to expect l10n to work out what to write. Even if bugs are not hidden there may well be a web of related bugs. l10n are not expected to be technical article writers, with the added burdon of all of our background material being in English.

    We compound the task by expecting l10n to do the work with nil notice, or a few days at best. We have 18 weeks of the change riding the trains with a team of writers and reviewers available to complete the work, and sometimes information to crib from professionals running Mozilla campaigns.

    Cheers, John

    Thanks Michał Yes I understand the locale switcher ;-) I just do not think repeated, late, ad-hoc comments are the way forward with this change of policy. It will be interesting to hear Joni's comments as hopefully a proper plan is being proposed to deal with this situation. <u>FORUM INSTRUCTIONS</u> You appear to favour going for a complicated manual method of explaining points to multiple individual locales. Such a method then probably buries information in this forum away from the article itself. That may be ok as a method of communicating with locales, but it is pretty bad as a method of writing, discussing & editing articles. '''If locales each write their own articles who reviews those ??''' The articles are no longer l10n needing only to be reviewed with respect to l10n they are new or at least important revisions. At the very least we need some formalised method of flagging and reviewing such articles. <u>KB INLINE INSTRUCTION & CONTENT </u> All we really need is a to write the original article to cover * Feature present * And feature absent, **Or feature modified. What I am saying is we should do this. Of course we need to know it is necessary. So we need to be kept informed about what is happening. Assuming trends continue we will repeatedly have this issue. Resorting to peppering articles with l10n remarks, and remmed out sections seems clumsy, confusing, and hard to maintain. What if any method do we have for * Sumo being notified * Individal l10n people being notified When either a feature changes or does not chage, i.e. the locale is forked ? <u>RESEARCH & PREPARATION</u> Someone in Rel Eng will know exactly what change goes in what locale, let's face it the code has to be changed or not. We could at a minimum add the information to the article discussion tab to say which locales have or do not have a feature. We should then write the article accordingly. What I suggest is we consider better methods than having to litter articles with l10n notes and preferably get this automated. We need to cope with the following because of '''locale forking''': * Feature may be present | Absent |modified * End users look at articles that have not been localised. * Automate RFL for important changes|forking ** Locales need to be '''aware''' which articles are '''important''' ** Locales need to be '''aware''' whether they are '''forked or not''' <blockquote>The good thing about the KB is that nowhere does it say that en-US articles have to be localized 1:1 into all the other locales - there can (and in some cases should, as we can see) '''discrepancies'''. I will talk to Joni about figuring out a best way of ensuring localizers can easily see what should and should not be localized for their locale when they get into the article localization view. <sub>my emphasis ~J99 </sub></blockquote> I consider we need to '''deal with the discrepancies when writing or modifying the article'''. We do not want locales reinventing the wheel and each writing their own article or version of an article. We want to make it easy for locales and have them localise parent article from en-US. If en-US writers & reviewers have difficulty figuring out what is happening it is unreasonable to expect l10n to work out what to write. Even if bugs are not hidden there may well be a web of related bugs. l10n are not expected to be technical article writers, with the added burdon of all of our background material being in English. We compound the task by expecting l10n to do the work with nil notice, or a few days at best. We have 18 weeks of the change riding the trains with a team of writers and reviewers available to complete the work, and sometimes information to crib from professionals running Mozilla campaigns. Cheers, John
  7. John99
    John99 3665 posts
    more options

    I guess there will be a messy situation with Firefox40 almost upon us and changes being made to product linked articles at short notice and some locales being forked.

    Also related

    <snip> Related Articles
    Revisions to this Article have been made and then quickly reversed because related articles are not ready. Apparently our own KB articles need marketing or whoever's approval. The linked articles were So maybe we are going to see rapid unexpected and unexplained revisions to those articles and they in turn link to More t words to be removed, and confusingly replaced with Sites. <snip>
    I guess there will be a messy situation with Firefox40 almost upon us and changes being made to product linked articles at short notice and some locales being forked. Also related * ''"[ATTN: Admin] Mozilla-employee-confidential bugs"''' [/forums/contributors/711462] * [/kb/about-tiles-new-tab/discuss/6194#post-12312] <blockquote> <snip> <u>Related Articles</u><br />Revisions to this Article have been made and then [https://support.mozilla.org/kb/about-tiles-new-tab/revision/101448 quickly reversed] because related articles are not ready. Apparently our own KB articles need marketing or whoever's approval. The linked articles were * [[Hide or display Tiles in New Tab]] * [[Customize the New Tab page]] So maybe we are going to see rapid unexpected and unexplained revisions to those articles and they in turn link to * [[About Tiles in New Tab]] * [[Hide or display Tiles in New Tab]] More t words to be removed, and confusingly replaced with Sites. <snip> </blockquote>
  8. John99
    John99 3665 posts
    more options

    My comments above will need considering in the light of Joni's comments on change of policy regarding tiles, and we will be getting more discussion links broken because of further article name changes.

    I wonder how many of us remember the guidelines on article freezes. Our guidelines are to try to give localisers 4 weeks notice of changes

    ===Top article "freeze"=== Localization is a lot of work and is often done by just one person. Only the top 20 or so articles get localized in some locales. Our top articles generally don't need any changes other than updates for a new version of Firefox. Since we know what's coming, we try to make sure that all required changes are done four weeks prior to a Firefox release so that localizers can use those four weeks for getting their work done. Therefore, we should only mark top articles as ready for localization four weeks before a release. All updates for the next six weeks should NOT be marked ready for localization. Of course if there is a change that is critical and should be translated, we'll have to make an exception.
    My comments above will need considering in the light of Joni's comments on change of policy regarding tiles, and we will be getting more discussion links broken because of further article name changes. I wonder how many of us remember the guidelines on article freezes. Our guidelines are to try to give localisers 4 weeks notice of changes * [[Article review guidelines#w_top-article-freeze|Article review guidelines_top-article-freeze]] <blockquote>===Top article "freeze"=== Localization is a lot of work and is often done by just one person. Only the top 20 or so articles get localized in some locales. Our top articles generally don't need any changes other than updates for a new version of Firefox. Since we know what's coming, we try to make sure that all required changes are done four weeks prior to a Firefox release so that localizers can use those four weeks for getting their work done. '''Therefore, we should only mark top articles as ready for localization four weeks before a release. All updates for the next six weeks should NOT be marked ready for localization.''' Of course if there is a change that is critical and should be translated, we'll have to make an exception.</blockquote>