feat: added extra translations for frontend-plugin-learner-dashboard

[jajjibhai008]

Description

Extends translation infrastructure to support frontend-plugin-learner-dashboard by adding it as a translation source in the Makefile's pull_translations target. This enables the internationalization workflow to extract, manage, and import plugin-specific translatable strings from the edx/openedx-translations repository.

[Copilot]

Pull request overview

This PR adds translation support for the frontend-plugin-learner-dashboard plugin by integrating it into the existing translation pipeline.

Key Changes:

• Introduced variable definitions (ATLAS_EXTRA_SOURCES and ATLAS_OPTIONS) to make translation sources more maintainable
• Extended the pull_translations target to include the new plugin's translation source
• Added the plugin to the intl_imports command to process imported translations

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.

[deborahgu]

The idea of making an $(ATLAS_EXTRA_SOURCES) a variable is so that this doesn't have to be a fork from upstream. So instead of using the variable but then hardcoding the repo on lines 16-17 and line 58, you should keep your line 56 here and have another variable on line 58 like $ATLAS_EXTRA_INTL_IMPORTS. That can go up to openedx so nobody needs to maintain a fork. Then you define the contents of those 2 variables, and the contents of ATLAS_OPTIONS, in edx-internal.

[MaxFrank13]

The idea of making an $(ATLAS_EXTRA_SOURCES) a variable is so that this doesn't have to be a fork from upstream. So instead of using the variable but then hardcoding the repo on lines 16-17 and line 58, you should keep your line 56 here and have another variable on line 58 like $ATLAS_EXTRA_INTL_IMPORTS. That can go up to openedx so nobody needs to maintain a fork. Then you define the contents of those 2 variables, and the contents of ATLAS_OPTIONS, in edx-internal.

With this suggestion, we can actually have this change on the Open edX repository. Since there would be no hardcoded, 2U-specific code in the repo at that point. Doing it this way, we will avoid diverging from the master branch of Open edX and also making future updates less of a pain.

So I would vote to point this PR to openedx/master instead of edx/release-ulmo. I believe you would need to create a new PR to do so as I don't believe there is a way to change the organization after the PR has been created.