internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: mozilla/pontoon

Issue:
Drop contributor profile URL with email addresses
We should drop support for accessing contributor profiles by using user email addresses in the URLs. This feature, while not used internally in the app, leaks otherwise hidden user email addressed on sites like on web.archive.org index.

This is particularly problematic for users without any contributions.



Discussion:

Resolving patch:
diff --git a/pontoon/contributors/urls.py b/pontoon/contributors/urls.py
--- a/pontoon/contributors/urls.py
+++ b/pontoon/contributors/urls.py
@@ -28,12 +28,6 @@ class UsernameConverter(StringConverter):
         views.ContributorsView.as_view(),
         name="pontoon.contributors",
     ),
-    # Contributor profile by email
-    path(
-        "contributors/<email:email>/",
-        views.contributor_email,
-        name="pontoon.contributors.contributor.email",
-    ),
     # Contributor profile by username
     path(
         "contributors/<username:username>/",


Test patch:
diff --git a/pontoon/contributors/tests/test_views.py b/pontoon/contributors/tests/test_views.py
--- a/pontoon/contributors/tests/test_views.py
+++ b/pontoon/contributors/tests/test_views.py
@@ -142,14 +142,6 @@ def test_profile_view_contributor_profile_by_username(member, mock_profile_rende
     assert mock_profile_render.call_args[0][2]["contributor"] == member.user
 
 
-@pytest.mark.django_db
-def test_profile_view_contributor_profile_by_email(member, mock_profile_render):
-    """Check if we can access contributor profile by its email."""
-    member.client.get(f"/contributors/{member.user.email}/")
-
-    assert mock_profile_render.call_args[0][2]["contributor"] == member.user
-
-
 @pytest.mark.django_db
 def test_profile_view_logged_user_profile(member, mock_profile_render):
     """Logged users should be able view their profiles"""
Repository: mozilla/pontoon

Issue:
Chosen pretranslated locales also listed Available in Admin
<img width="665" alt="Screenshot 2023-03-07 at 22 29 01" src="https://user-images.githubusercontent.com/626716/223557116-e7ef8771-8028-4655-ad93-76f9e6aabf02.png">


Discussion:

Resolving patch:
diff --git a/pontoon/administration/views.py b/pontoon/administration/views.py
--- a/pontoon/administration/views.py
+++ b/pontoon/administration/views.py
@@ -259,11 +259,16 @@ def manage_project(request, slug=None, template="admin_project.html"):
         pk__in=locales_selected
     )
 
+    locales_pretranslate_available = locales_selected.exclude(
+        pk__in=locales_pretranslate
+    )
+
     # Admins reason in terms of locale codes (see bug 1394194)
     locales_readonly = locales_readonly.order_by("code")
     locales_selected = locales_selected.order_by("code")
     locales_available = locales_available.order_by("code")
     locales_pretranslate = locales_pretranslate.order_by("code")
+    locales_pretranslate_available = locales_pretranslate_available.order_by("code")
 
     data = {
         "slug": slug,
@@ -276,6 +281,7 @@ def manage_project(request, slug=None, template="admin_project.html"):
         "locales_selected": locales_selected,
         "locales_available": locales_available,
         "locales_pretranslate": locales_pretranslate,
+        "locales_pretranslate_available": locales_pretranslate_available,
         "subtitle": subtitle,
         "pk": pk,
         "project": project,


Test patch:
Repository: mozilla/pontoon

Issue:
Sort tags on dashboard by priority
*This issue was created automatically by a [script](https://github.com/mathjazz/bugzilla2github/).*
## [Bug 1701174](https://bugzilla.mozilla.org/show_bug.cgi?id=1701174)
Bug Reporter: @MikkCZ
CC:   @mathjazz

Currently the tags on dashboard seem to be sorted somewhat randomly. I would very appreciate to have them sorted by priority (5 star at the top), so I know what to look on first.
Sort tags on dashboard by priority
*This issue was created automatically by a [script](https://github.com/mathjazz/bugzilla2github/).*
## [Bug 1701174](https://bugzilla.mozilla.org/show_bug.cgi?id=1701174)
Bug Reporter: @MikkCZ
CC:   @mathjazz

Currently the tags on dashboard seem to be sorted somewhat randomly. I would very appreciate to have them sorted by priority (5 star at the top), so I know what to look on first.


Discussion:
Comment Author: @mathjazz

Note that this would also be consistent with the behavior in the Filters panel of the Translate view.


Comment Author: @mathjazz

Note that this would also be consistent with the behavior in the Filters panel of the Translate view.



Resolving patch:
diff --git a/pontoon/localizations/views.py b/pontoon/localizations/views.py
--- a/pontoon/localizations/views.py
+++ b/pontoon/localizations/views.py
@@ -1,5 +1,5 @@
 import math
-
+from operator import attrgetter
 from django.conf import settings
 from django.core.exceptions import ImproperlyConfigured
 from django.db.models import Q
@@ -170,10 +170,12 @@ def ajax_tags(request, code, slug):
         priority=True,
     )
 
+    tags = sorted(tags_tool, key=attrgetter("priority"), reverse=True)
+
     return render(
         request,
         "localizations/includes/tags.html",
-        {"locale": locale, "project": project, "tags": list(tags_tool)},
+        {"locale": locale, "project": project, "tags": tags},
     )
 
 
diff --git a/pontoon/projects/views.py b/pontoon/projects/views.py
--- a/pontoon/projects/views.py
+++ b/pontoon/projects/views.py
@@ -1,5 +1,5 @@
 import uuid
-
+from operator import attrgetter
 from django.conf import settings
 from django.contrib.auth.models import User
 from django.contrib.contenttypes.models import ContentType
@@ -110,10 +110,12 @@ def ajax_tags(request, slug):
         priority=True,
     )
 
+    tags = sorted(tags_tool, key=attrgetter("priority"), reverse=True)
+
     return render(
         request,
         "projects/includes/tags.html",
-        {"project": project, "tags": list(tags_tool)},
+        {"project": project, "tags": tags},
     )
 
 


Test patch:
Repository: mozilla/pontoon

Issue:
New string notifications should always link to translate view
If the user hasn't set their custom [homepage](https://mozilla-l10n.github.io/localizer-documentation/tools/pontoon/users.html#locale-settings) (2/3 of the PMO user base), [new string notifications](https://mozilla-l10n.github.io/localizer-documentation/tools/pontoon/notifications.html#new-strings) link to project dashboards, rather than to the translate view.

We should always link to the [locale-agnostic translate view](https://github.com/mozilla/pontoon/blob/master/pontoon/base/views.py#L57), which only links to the dashboard in case the custom homepage isn't set and the user locale cannot be determined using the `Accept-Language` header.

See also:
https://github.com/mozilla/pontoon/pull/1989/files/b404f21cfe312f2020a33265706aad8a56fd00a5#diff-4ebc5e9888b2962aecd470dd76f7d410b4e246f2d8323df57ed7dd0c8d5e3ade


Discussion:

Resolving patch:
diff --git a/pontoon/base/models.py b/pontoon/base/models.py
--- a/pontoon/base/models.py
+++ b/pontoon/base/models.py
@@ -351,7 +351,7 @@ def serialized_notifications(self):
         is_comment = False
 
         if hasattr(notification.actor, "slug"):
-            if "new string" in notification.verb and self.profile.custom_homepage:
+            if "new string" in notification.verb:
                 actor = {
                     "anchor": notification.actor.name,
                     "url": reverse(


Test patch:
Repository: mozilla/pontoon

Issue:
Show when source string was created in Metadata
We store Entity creation timestamp in `Entity.date_created`. We should show that information in the Metadata section of the translate view.


Discussion:

Resolving patch:
diff --git a/pontoon/base/models.py b/pontoon/base/models.py
--- a/pontoon/base/models.py
+++ b/pontoon/base/models.py
@@ -3076,6 +3076,7 @@ def map_entities(
                     "translation": translation_array,
                     "readonly": entity.resource.project.projectlocale[0].readonly,
                     "is_sibling": is_sibling,
+                    "date_created": entity.date_created,
                 }
             )
 


Test patch:
diff --git a/pontoon/base/tests/models/test_entity.py b/pontoon/base/tests/models/test_entity.py
--- a/pontoon/base/tests/models/test_entity.py
+++ b/pontoon/base/tests/models/test_entity.py
@@ -327,6 +327,7 @@ def test_entity_project_locale_no_paths(
         "machinery_original": str(entity_a.string),
         "readonly": False,
         "is_sibling": False,
+        "date_created": entity_a.date_created,
     }
     assert entities[0] == expected
 
diff --git a/translate/src/modules/entitydetails/components/EntityDetails.test.js b/translate/src/modules/entitydetails/components/EntityDetails.test.js
--- a/translate/src/modules/entitydetails/components/EntityDetails.test.js
+++ b/translate/src/modules/entitydetails/components/EntityDetails.test.js
@@ -14,6 +14,7 @@ const ENTITY = (pk) => ({
   translation: [{ string: 'test', errors: [], warnings: [] }],
   project: { contact: '' },
   comment: '',
+  date_created: new Date().toISOString(),
 });
 
 function mockEntityDetails(pk) {
diff --git a/translate/src/modules/entitydetails/components/Metadata.test.js b/translate/src/modules/entitydetails/components/Metadata.test.js
--- a/translate/src/modules/entitydetails/components/Metadata.test.js
+++ b/translate/src/modules/entitydetails/components/Metadata.test.js
@@ -20,6 +20,7 @@ const ENTITY = {
     slug: 'callme',
     name: 'CallMe',
   },
+  date_created: new Date().toISOString(),
 };
 
 const LOCALE = {
Repository: mozilla/pontoon

Issue:
Import translations not working for WebExtension project
I've enabled pt-PT for Multi-account container
https://pontoon.mozilla.org/pt-PT/firefox-multi-account-containers/

Then I tried to import translations from an existing `messages.json` file (coming from [this PR](https://github.com/mozilla-l10n/multi-account-containers-l10n/pull/24)). Pontoon says "translations imported", but nothing it's imported, and the log doesn't show anything useful.

I ended up merging the PR and syncing, all translations were imported as expected.


Discussion:
I can reproduce the issue. It seems to be specific for the `messages.json`. I couldn't reproduce with .po, .ftl or .xliff.

Resolving patch:
diff --git a/pontoon/base/utils.py b/pontoon/base/utils.py
--- a/pontoon/base/utils.py
+++ b/pontoon/base/utils.py
@@ -337,12 +337,13 @@ def handle_upload_content(slug, code, part, f, user):
     project = get_object_or_404(Project, slug=slug)
     locale = get_object_or_404(Locale, code=code)
     resource = get_object_or_404(Resource, project__slug=slug, path=part)
-
     # Store uploaded file to a temporary file and parse it
     extension = os.path.splitext(f.name)[1]
+    is_messages_json = f.name.endswith("messages.json")
+
     with tempfile.NamedTemporaryFile(
         prefix="strings" if extension == ".xml" else "",
-        suffix=extension,
+        suffix=".messages.json" if is_messages_json else extension,
     ) as temp:
         for chunk in f.chunks():
             temp.write(chunk)
diff --git a/pontoon/sync/formats/__init__.py b/pontoon/sync/formats/__init__.py
--- a/pontoon/sync/formats/__init__.py
+++ b/pontoon/sync/formats/__init__.py
@@ -25,7 +25,7 @@
     "*.ftl": ftl.parse,
     "*.inc": silme.parse_inc,
     "*.ini": silme.parse_ini,
-    "messages.json": json_extensions.parse,
+    "*messages.json": json_extensions.parse,
     "*.json": json_keyvalue.parse,
     "*.lang": lang.parse,
     "*.po": po.parse,


Test patch:
Repository: mozilla/pontoon

Issue:
Error rather than warn on empty strings.xml translations
The current handling of empty translations in Pontoon works like this:
* If the file format does not allow storing empty values, Pontoon shows an error when the user tries to submit an empty translation. Errors cannot be superseded, so submitting an empty translation is impossible.
* If the file format allows storing empty values, Pontoon shows a warning when the user tries to submit an empty translation. Warning can be superseded, so submitting an empty translation is possible.

Since we:
* don’t have any empty en-US strings in strings.xml files,
* can't find a good use case for empty strings,
* see empty translations being submitted by mistake,

we'd like to change this behavior and error also on empty translation submissions to strings.xml files.


Discussion:

Resolving patch:
diff --git a/pontoon/base/models.py b/pontoon/base/models.py
--- a/pontoon/base/models.py
+++ b/pontoon/base/models.py
@@ -2173,7 +2173,6 @@ class Format(models.TextChoices):
         Format.INC,
         Format.INI,
         Format.PROPERTIES,
-        Format.XML,
     }
 
     objects = ResourceQuerySet.as_manager()


Test patch:
Repository: mozilla/pontoon

Issue:
Pontoon fails to approve string translation
Pontoon: https://pontoon.mozilla.org/zh-TW/sumo/all-resources/?string=263159
String repo: https://github.com/mozilla-l10n/sumo-l10n/blob/master/zh_TW/LC_MESSAGES/django.po#L3313-L3317

# STR
1. Open the string on Pontoon.
2. Submit and approve the translation (there's already one with 100% TM match)
3. Reload Pontoon page for the same string

# Expected 
The translation was saved and approved correctly

# Actual 
1. The string seems to be not approved in the translation area, however it is approved in the submission area.
1. By submitting the translation with the existing translation using Enter key, "Same translation already exist" displays every time.
2. By un-approving and approving the string again, the string seems to be approved. However refreshing the page the string became unapproved again.



Discussion:
I can replicate the bug locally, for translations of Gettext strings with plural forms into locales (such as zh-TW) that don't use them. It looks like they're getting stored with the `plural_form` field left empty rather than set to `0`.

@mathjazz There are at least a couple of ways we could fix this:
1. Revert the client change that I made at some point which broke this, and fix the data.
2. Fix our queries to ignore the `plural_form` in locales with just one plural category.

Got a preference?
I'd prefer data to be consistent, so 1.

Resolving patch:
diff --git a/pontoon/base/migrations/0049_fix_pluralform_data.py b/pontoon/base/migrations/0049_fix_pluralform_data.py
new file mode 100644
--- /dev/null
+++ b/pontoon/base/migrations/0049_fix_pluralform_data.py
@@ -0,0 +1,23 @@
+from django.db import migrations
+
+
+def fix_gettext_plural_forms(apps, schema_editor):
+    Translation = apps.get_model("base", "Translation")
+    broken = Translation.objects.filter(plural_form__isnull=True).exclude(
+        entity__string_plural=""
+    )
+    broken.update(plural_form=0)
+
+
+class Migration(migrations.Migration):
+
+    dependencies = [
+        ("base", "0048_userprofile_theme"),
+    ]
+
+    operations = [
+        migrations.RunPython(
+            code=fix_gettext_plural_forms,
+            reverse_code=migrations.RunPython.noop,
+        ),
+    ]


Test patch:
Repository: mozilla/pontoon

Issue:
Rename Firefox accounts in Mozilla accounts
There are a few references in the documentation, we should update them.
I think renaming internal references (e.g. fxa) goes beyond the scope, as most products will keep that for the time being.

We also need to make sure to update whatever package is responsible for the text in [this page](https://pontoon.mozilla.org/accounts/fxa/login/)


Discussion:

Resolving patch:
diff --git a/pontoon/settings/base.py b/pontoon/settings/base.py
--- a/pontoon/settings/base.py
+++ b/pontoon/settings/base.py
@@ -956,7 +956,7 @@ def account_username(user):
 ACCOUNT_EMAIL_VERIFICATION = "none"
 ACCOUNT_USER_DISPLAY = account_username
 
-# Firefox Accounts
+# Mozilla Accounts (formerly Firefox Accounts)
 FXA_CLIENT_ID = os.environ.get("FXA_CLIENT_ID")
 FXA_SECRET_KEY = os.environ.get("FXA_SECRET_KEY")
 FXA_OAUTH_ENDPOINT = os.environ.get("FXA_OAUTH_ENDPOINT", "")


Test patch:
Repository: mozilla/pontoon

Issue:
Plural rule breaks js code
In migration https://github.com/mozilla/pontoon/blob/main/pontoon/base/migrations/0002_auto_20200322_1821.py#L722
The plural rule contains "or" operator instead of "||"
The client script https://github.com/mozilla/pontoon/blob/main/translate/src/hooks/usePluralExamples.ts#L25
tries to evaluate the plural formula directly as js code and crashes
![image](https://github.com/mozilla/pontoon/assets/332556/f9098505-e986-47a3-bb6d-e340c2f4dede)

We plan to add a workaround for this in our installation https://translate.zabbix.com/lt/zabbix-64/LC_MESSAGES/frontend.po/?string=119281
```

diff --git a/translate/src/hooks/usePluralExamples.ts b/translate/src/hooks/usePluralExamples.ts
index 239d32e5..c7fbc73f 100644
--- a/translate/src/hooks/usePluralExamples.ts
+++ b/translate/src/hooks/usePluralExamples.ts
@@ -22,7 +22,7 @@ export function usePluralExamples(locale: Locale): Record<number, number> {
       return { [one]: 1, [other]: 2 };
     }

-    const fnBody = `return Number(${pluralRule})`;
+    const fnBody = `return Number(${pluralRule.replace('or', '||')})`;
     const getRule = new Function('n', fnBody) as (n: number) => number;

     let found = 0;
```
Would be nice to have this fixed in upstream by adding migration that corrects the plural formula.
Or even better: have pontoon take the plural formula from the project translation files instead of it being hardcoded.


Discussion:
Thanks for the report! 

I guess we fixed it in our production instance, and didn't notice it locally because we use DB dumps.

Let's indeed add a migration file to address this.

(We cannot take the plural formula from the translation files for non-Gettext formats).

Resolving patch:
diff --git a/pontoon/base/migrations/0047_fix_lt_plural_rule.py b/pontoon/base/migrations/0047_fix_lt_plural_rule.py
new file mode 100644
--- /dev/null
+++ b/pontoon/base/migrations/0047_fix_lt_plural_rule.py
@@ -0,0 +1,26 @@
+# Generated by Django 3.2.15 on 2023-10-17 07:09
+
+from django.db import migrations
+
+
+def fix_lt_plural_rule(apps, schema_editor):
+    Locale = apps.get_model("base", "Locale")
+    locale = Locale.objects.get(code="lt")
+    locale.plural_rule = (
+        "(n%10==1 && n%100!=11 ? 0 : n%10>=2 && (n%100<10 || n%100>=20) ? 1 : 2)"
+    )
+    locale.save(update_fields=["plural_rule"])
+
+
+class Migration(migrations.Migration):
+
+    dependencies = [
+        ("base", "0046_projectslughistory"),
+    ]
+
+    operations = [
+        migrations.RunPython(
+            code=fix_lt_plural_rule,
+            reverse_code=migrations.RunPython.noop,
+        ),
+    ]


Test patch:
Repository: mozilla/pontoon

Issue:
GetText check fails incorrectly on newline
https://pontoon.mozilla.org/en-GB/all-projects/all-resources/?string=286055

If you copy the source string, an extra line is added at the back, and that fails the checks for GetText.


Discussion:
COPY works as expected: source strings ends with a newline, which gets copied to the translation area.

What is surprising is that the newline check fails:
https://github.com/mozilla/pontoon/blob/main/pontoon/checks/libraries/pontoon_db.py#L73

I was able to submit the translation without a problem yesterday, but not today:
https://pontoon.mozilla.org/sl/all-projects/all-resources/?string=286055

@eemeli, could it be that #2926 fixes it? I don't see anything pointing that way there.
Another example https://pontoon.mozilla.org/en-GB/all-projects/all-resources/?string=286198
I encountered an additional complication today in dealing with this error - when trying to adjust whitespace to a suggestion to correct this error I wasn't able to save/approve a translation. The editor wasn't considering changes to the whitespace as changes to the string, so it'd keep trying to approve the string that was triggering the newline error. For example [this string](https://pontoon.mozilla.org/da/firefox-accounts/LC_MESSAGES/client.po/?string=286060):  I had to add a space after the "du:" and before the <br /> to make the translation "different" and allowed me to save it. Otherwise it'd still consider this the same as the previous suggestion and only allow me to "approve". (Which would fail the newline check.)
This looks like a back-end bug. Testing with [this string](https://mozilla-pontoon-staging.herokuapp.com/fi/all-projects/all-resources/?string=192448) (the only non-obsolete gettext string with a trailing newline I could find), copy+suggest POSTs to `/translations/create/` with a `translation` value that exactly matches the source, including the trailing newline, but receives a `pErrors: [ "Ending newline mismatch" ]`.

Resolving patch:
diff --git a/pontoon/translations/forms.py b/pontoon/translations/forms.py
--- a/pontoon/translations/forms.py
+++ b/pontoon/translations/forms.py
@@ -51,5 +51,8 @@ def clean_plural_form(self):
             return None
         return self.cleaned_data["plural_form"]
 
+    def clean_original(self):
+        return self.data.get("original", "")
+
     def clean_translation(self):
         return self.data.get("translation", "")


Test patch:
Repository: mozilla/pontoon

Issue:
Broken heroku deploy button
When i try to deploy pontoon on heroku, i got an infinite charge..
![image](https://user-images.githubusercontent.com/39674510/159341794-4393827a-5b36-49b7-89b4-52b9602d1e72.png)

I just clicked on button from README file and logged in to heroku platform


Discussion:
Thanks for reporting!

Could you please confirm that you can deploy from the button in the docs?
https://mozilla-pontoon.readthedocs.io/en/latest/admin/deployment.html
@mathjazz yeah, with this button it works
but login does not works...
i used admin email and admin password
Do You mean Heroku login or Pontoon login?

If Pontoon, you need to create an admin account first:
https://mozilla-pontoon.readthedocs.io/en/latest/admin/deployment.html#creating-an-admin-user
Ok Thanks, there was my mistake
The issue with the Heroku Deploy button in the repository is still a valid issue.
I came across this problem too. When I use the button, I get taken to the Heroku `Create New App` page, which loads UI, but no resources show in the `Resources` section of the page and the `Add to pipeline…` button does nothing.

![CleanShot 2023-03-14 at 14 11 33@2x](https://user-images.githubusercontent.com/11338/225029391-773667b3-553a-4f0d-acb9-53a0a4a13d50.png)

There are some errors in the JS console for the Heroku site which makes me think this is a Heroku issue. 

<img width="800" alt="CleanShot 2023-03-14 at 14 16 37@2x" src="https://user-images.githubusercontent.com/11338/225029579-28b69b81-1fe7-45f8-bde0-b74898bfc179.png">


Confirming I can reproduce the issue.

Workaround with using the button on https://mozilla-pontoon.readthedocs.io/en/latest/admin/deployment.html#creating-an-admin-user is no longer possible.

Resolving patch:
diff --git a/pontoon/base/management/commands/heroku_deploy_setup.py b/pontoon/base/management/commands/heroku_deploy_setup.py
--- a/pontoon/base/management/commands/heroku_deploy_setup.py
+++ b/pontoon/base/management/commands/heroku_deploy_setup.py
@@ -1,11 +1,11 @@
 import os
 
-from urllib.parse import urlparse, urljoin
+from urllib.parse import urlparse
 
 from django.core.management.base import BaseCommand
 from django.contrib.sites.models import Site
 
-from pontoon.base.models import Project, User
+from pontoon.base.models import User
 
 
 class Command(BaseCommand):
@@ -19,7 +19,3 @@ def handle(self, *args, **options):
 
         User.objects.create_superuser(admin_email, admin_email, admin_password)
         Site.objects.filter(pk=1).update(name=app_host, domain=app_host)
-
-        Project.objects.filter(slug="pontoon-intro").update(
-            url=urljoin(site_url, "intro/")
-        )


Test patch: