Can't compile translation catalog when installing from source

aulemahal commented 7 months ago

Setup Information

xscen version: latest
Python version: all
Operating System: any

Description

The setuptools hack we added in setup.py only works for pip install . or pip install xscen, but no when the argument is a git url or if the -e option is specified. This is gossing.

Steps To Reproduce

pip install git+https://github.com/ouranosinc/xscen.git
python -c "import xscen"

Additional context

Opinion : I though gettext and babel would help the work of translating xscen. I do not have that feeling anymore. For some reason, babel only canonically works with setuptools.

There would alternatives : we might be able to hack something by using a build backend that allows running custom commands during the build process (poetry seems to allow that).

OR : we go back to the simple method that xclim uses : put all the strings in a text file (yaml would be better than json). In the end, gettext only... gets texts. We could reimplement the core of what we use from it in only 5-6 lines. And remove the need for "compilation" completely.

Contribution

[X] I would be willing/able to open a Pull Request to address this bug.

RondeauG commented 7 months ago

I don't have any strong reason to keep gettext if it complicates things needlessly. For now, we indeed only translate a very limited number of lines.

juliettelavoie commented 7 months ago

with "-e", can you do "make translate" by hand ?

For translation tools,I don't have a strong opinion.

RondeauG commented 7 months ago

My understanding is that this is essentially an issue when trying to install xscen without going through PyPI/conda. In other words, it's mostly an hassle for developers, which is why I don't have a strong opinion on keeping or removing it.

However for our current needs, it might be overcomplicated.

Edit: make translate doesn't work on Windows, but python setup.py compile_catalog does. At minimum, we should have that info somewhere.

Zeitsperre commented 7 months ago

Edit: make translate doesn't work on Windows, but python setup.py compile_catalog does. At minimum, we should have that info somewhere.

If we want, we can change the way that a Makefile command is called depending on the platform it's running on. This is a very standard practice. If a user is using make commands, they should work for all platforms.

we might be able to hack something by using a build backend that allows running custom commands during the build process (poetry seems to allow that).

Good idea. I was thinking this might happen, so perhaps you could explore this option (https://github.com/taskipy/taskipy). I've contributed it to conda-forge as well.

We could reimplement the core of what we use from [xclim] in only 5-6 lines. And remove the need for "compilation" completely.

Would it make sense to expose this functionality in xclim? I know that other downstream projects (hydro) are also reliant on translation.

aulemahal commented 7 months ago

The make issue could easily be "fixed" by simply documenting the process. Our makefile really is just a map of aliases.

Would it make sense to expose this functionality in xclim?

Yes, but the idea is still fuzzy in my head:

xclim requires a structured translation database, i.e. specific snippets are associated to specific python objects (indicator -> attribute). There's a 1-to-1 relation from translation to python object. And the database can be very large, it has to have some structure for easier human edition.
figanos has a need for a very shallow dataset, with only a few terms needing translation, but those terms being potentially used in many places (functions). The database is very small.
xscen is in between. Most translations are to be used in specific places, but those underlying objects are not as structured as xclim's indicators (functions vs objects). The database will likely stay small, but who knows...

I'll suggest something soon.

Ouranosinc / xscen