README for Staff Graded XBlock
Testing with Docker
This XBlock comes with a Docker test environment ready to build, based on the xblock-sdk workbench. To build and run it:
$ make dev.run
The XBlock SDK Workbench, including this XBlock, will be available on the list of XBlocks at http://localhost:8000
Translating
Internationalization (i18n) is when a program is made aware of multiple languages. Localization (l10n) is adapting a program to local language and cultural habits.
Use the locale directory to provide internationalized strings for your XBlock project. For more information on how to enable translations, visit the Open edX XBlock tutorial on Internationalization.
This cookiecutter template uses django-statici18n to provide translations to static javascript using gettext.
The included Makefile contains targets for extracting, compiling and validating translatable strings. The general steps to provide multilingual messages for a Python program (or an XBlock) are:
Mark translatable strings.
Run i18n tools to create raw message catalogs.
Create language specific translations for each message in the catalogs.
Use gettext to translate strings.
1. Mark translatable strings
Mark translatable strings in python:
from django.utils.translation import ugettext as _
# Translators: This comment will appear in the `.po` file.
message = _("This will be marked.")
See edx-developer-guide for more information.
You can also use gettext to mark strings in javascript:
// Translators: This comment will appear in the `.po` file.
var message = gettext("Custom message.");
See edx-developer-guide for more information.
2. Run i18n tools to create Raw message catalogs
This cookiecutter template offers multiple make targets which are shortcuts to use edx-i18n-tools.
After marking strings as translatable we have to create the raw message catalogs. These catalogs are created in .po files. For more information see GNU PO file documentation. These catalogs can be created by running:
$ make extract_translations
The previous command will create the necessary .po files under staff_graded-xblock/staff_graded/locale/en/LC_MESSAGES/text.po. The text.po file is created from the django-partial.po file created by django-admin makemessages (makemessages documentation), this is why you will not see a django-partial.po file.
3. Create language specific translations
3.1 Add translated strings
After creating the raw message catalogs, all translations should be filled out by the translator. One or more translators must edit the entries created in the message catalog, i.e. the .po file(s). The format of each entry is as follows:
# translator-comments A. extracted-comments #: reference… #, flag… #| msgid previous-untranslated-string msgid 'untranslated message' msgstr 'mensaje traducido (translated message)'
For more information see GNU PO file documentation.
To use translations from transifex use the follow Make target to pull translations:
$ make pull_translations
See config instructions for information on how to set up your transifex credentials.
See transifex documentation for more details about integrating django with transiflex.
3.2 Compile translations
Once translations are in place, use the following Make target to compile the translation catalogs .po into .mo message files:
$ make compile_translations
The previous command will compile .po files using django-admin compilemessages (compilemessages documentation). After compiling the .po file(s), django-statici18n is used to create language specific catalogs. See django-statici18n documentation for more information.
To upload translations to transiflex use the follow Make target:
$ make push_translations
See config instructions for information on how to set up your transifex credentials.
See transifex documentation for more details about integrating django with transiflex.
Note: The dev.run make target will automatically compile any translations.
Note: To check if the source translation files (.po) are up-to-date run:
$ make detect_changed_source_translations
4. Use gettext to translate strings
Django will automatically use gettext and the compiled translations to translate strings.
Troubleshooting
If there are any errors compiling .po files run the following command to validate your .po files:
$ make validate
See django’s i18n troubleshooting documentation for more information.
Metadata
Release files for staff-graded-xblock 4.1.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| staff_graded_xblock-4.1.0.tar.gz | 125.3 kB | With provenance | Details for staff_graded_xblock-4.1.0.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| staff_graded_xblock-4.1.0-py3-none-any.whl | Python 3 | none | any | Details for staff_graded_xblock-4.1.0-py3-none-any.whl |
Total release size: 148.3 kB
Release files / staff_graded_xblock-4.1.0.tar.gz
| Download URL | staff_graded_xblock-4.1.0.tar.gz |
|---|---|
| Size | 125.3 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
f6d78c063883e5283310945af39e764838fcaf99efc352fef31227e71c239789
|
|
BLAKE2b-256 checksum How to use checksums |
fc24095bc04ed37d16894f454c7155137fa783c7428b510e9ae54bd9b93dc1c6
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 29, 2026.
Transparency logRelease files / staff_graded_xblock-4.1.0-py3-none-any.whl
| Download URL | staff_graded_xblock-4.1.0-py3-none-any.whl |
|---|---|
| Size | 23.0 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
c950de3762d0eeae07403b3b11105e567a8444c2c531a1cd721f54737d001793
|
|
BLAKE2b-256 checksum How to use checksums |
cc0340806148c937662ccc323cedc22f0295a891cfb9a8281b17986f596b65f6
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 29, 2026.
Transparency logSecurity for staff-graded-xblock 4.1.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for staff_graded_xblock-4.1.0.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 29, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.