![]() The list of your saved searches can be displayed by clicking in the search field at the top of the page: you simply need to click one of the items to perform the search.Īt the bottom of the page displaying search results, there’s a link to delete the saved search just performed ( Forget Search “NAME”). When the results appear, you can use the Remember search button and input field to save this search. Expand the Custom Search section at the bottom, and set it to Locale + contains the string + it.For example, let’s create a search for bugs reported against Italian in :: L10N. In Bugzilla, it’s possible to perform searches, and save them as templates. In order to receive emails for unconfirmed bugs, you need to update the Email Preferences in your profile, removing the flag from the Component column in the line The bug is in the UNCONFIRMED state. By default, bugs marked as UNCONFIRMED won’t send any notification.It’s not possible to follow a single locale within a component, for example for :: L10N.There are a few limitations to this approach: From this moment, you will receive an email for all bugs filed in – or moved to – that component. The product will appear in the section You are currently watching: right below. In the right section, select Mozilla Localizations as product, then your locale in the Component list.Select Component Watching in the left sidebar.Open your account preferences on Bugzilla.The simplest way to keep your bugs under control is to follow your locale in Mozilla Localizations: Follow the Bugzilla component for your locale The simplest way to do it is to use the BUGS tab on their team page in Pontoon. Triage localization bugsĮach localization team should keep an eye on bugs filed for their languages. More information about Bugzilla are available in this guide. If you’re reporting a bug for a specific string, you should trace back that string to a bug, and file your report in the same product and component. In case of doubt on which product or component to pick, Firefox :: Untriaged is usually a good starting point for Firefox bugs. a window is too narrow or a string is hardcoded, it’s a product bug, and should be filed accordingly. If the issue needs work from a developer, e.g.it’s about a typo or mistranslation, it should be filed in Mozilla Localizations :: Language or :: L10N. If the issue can be fixed by the localization team, e.g.When filing new bugs, the rule of thumb is: ![]() INCOMPLETE: the bug doesn’t contain enough information to reproduce it, or a clear description of the issue.WORKSFORME: it wasn’t possible to reproduce the bug.DUPLICATE: the problem is a duplicate of an existing bug. ![]() WONTFIX: the problem described is a bug which will never be fixed.INVALID: the problem described is not a bug.FIXED: the bug was fixed by a specific action.When a bug is marked as RESOLVED, there is an additional information that describes the type of resolution: NEW: the bug has been confirmed, but it still requires action.By default, a new user can only submit bugs as unconfirmed. UNCONFIRMED: the bug was reported but it’s not confirmed yet.For some components, there is also a Locale field, that allows selecting one or more languages affected.Ī bug has a status, the most common ones are: Mozilla Localizations :: it / Italian or :: L10N. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |