Move translation of some enumerations to backend

[jpmckinney]

Follow-up #342

Presently, most error messages are returned in English. A few are returned as codes, that get mapped to Spanish by the frontend. (See Frontend page in docs.)

This is unnecessary coupling. If we use gettext #357 (or even stick with Transifex), we can return good error messages in the default language (neither the frontend or backend have any language switching features) from the backend.

If i18n is implemented, we can remove the documentation, the ERROR_CODES enum, and the corresponding logic in the frontend. That said, we can add i18n without touching the frontend at all – we'd only need to touch it to remove the unnecessary logic.

[yolile]

As part of this, we could also create endpoints to return:

• borrower_size
• borrower_sector
• document_types

So we can get rid of that unnecessary coupling as well.

[jpmckinney]

Cool. Blocked by #357 which implements gettext (I could separate it from that PR if needed).

[yolile]

I'm reviewing that PR now so it should be merged soon

[jpmckinney]

@yolile For your comment, you can also update the part of frontend.rst that lists enums for:

Credere frontend's src/constants/index.ts constants should match app.models enumerations.

[jpmckinney]

With #382 you can generate a mapping from database name to translated text with e.g.:

from app import models
from app.i18n import _

{name: _(name) for name in models.ApplicationStatus}
# {'PENDING': 'Pendiente', 'DECLINED': 'Declinado', 'ACCEPTED': 'Aceptado', 'SUBMITTED': 'Enviado', 'STARTED': 'Empezado', 'REJECTED': 'Rechazado', 'INFORMATION_REQUESTED': 'Información solicitada', 'LAPSED': 'Caducado', 'APPROVED': 'Precalificado', 'CONTRACT_UPLOADED': 'Contrato cargado', 'COMPLETED': 'Completado'}

[jpmckinney]

Renaming issue for remaining task

[yolile]

Any preference for where to put this new endpoint? I'm thinking of a generic get_settings one, that receives a key as a parameter and returns labels and values. The different settings belong to different forms, including public and private ones. I could create a new file and put the new endpoint there, and make it public.

[jpmckinney]

For inspiration, GitHub uses /meta for metadata: https://docs.github.com/en/rest/meta/meta?apiVersion=2022-11-28

One option is to just have one endpoint /meta for all our constants. I don't think any of the constants we want to return are insecure or private (document types, etc.).

If so, we can have a routers/guest/meta.py file (since even if accessed to render a private page, the endpoint itself doesn't require authentication/authorization).

Or, we can have individual endpoints for each constant...

But, I think it'll be easier going forward to just have one endpoint. It will require fewer changes across the two repos.