FS#59278 - No translation file found for domain: 'aur'

Attached to Project: AUR web interface
Opened by Stefan Auditor (sanduhrs) - Monday, 09 July 2018, 09:00 GMT
Last edited by Lukas Fleischer (lfleischer) - Tuesday, 21 April 2020, 16:10 GMT
Task Type Bug Report
Category Backend
Status Closed
Assigned To Eli Schwartz (eschwartz)
Architecture All
Severity Low
Priority Normal
Reported Version 4.7.0
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Pushing a new package version to the aur brings up an error message:
"remote: FileNotFoundError: [Errno 2] No translation file found for domain: 'aur'"

Push goes through nonetheless.
Full output attached.
   log.txt (1.3 KiB)
This task depends upon

Closed by  Lukas Fleischer (lfleischer)
Tuesday, 21 April 2020, 16:10 GMT
Reason for closing:  Fixed
Comment by Eli Schwartz (eschwartz) - Monday, 09 July 2018, 13:10 GMT
  • Field changed: Status (Unconfirmed → Assigned)
  • Field changed: Reported Version (4.6.0 → 4.7.0)
  • Task assigned to Eli Schwartz (eschwartz)
Comment by Eli Schwartz (eschwartz) - Monday, 09 July 2018, 14:30 GMT
The live instance is patched, so you should no longer see this issue.
Comment by Mark Blakeney (bulletmark) - Friday, 20 July 2018, 14:56 GMT
I'm still getting these errors. Pushed 2 packages tonight and got this error on both. I also got it previous push on 16-July.
Comment by Eli Schwartz (eschwartz) - Friday, 20 July 2018, 15:00 GMT
Yes, see https://lists.archlinux.org/pipermail/aur-general/2018-July/034170.html for more reports, but now that the domain is fixed we're just getting errors that the correct translation cannot be found either???

Not entirely sure what is happening here, it's the same translation code as the previous release and the only thing which changed is the name.
Comment by Lukas Fleischer (lfleischer) - Friday, 20 July 2018, 15:26 GMT
That's not true. There was no translation of the notification emails in the previous release...
Comment by Lukas Fleischer (lfleischer) - Friday, 20 July 2018, 15:27 GMT
Something might be broken; I'd guess it's the path issue you pointed out earlier (it's relative in the translator but the translators are started from a different location when installed).
Comment by Eli Schwartz (eschwartz) - Friday, 20 July 2018, 15:33 GMT
Oof, you're right.

...

Hmm, that makes the problem more obvious then. I guess the python code cannot detect the proper locale directory since it is installed as a site-packages module instead of being run from the live checkout, whereas the php code is a live checkout.

Do we want to install the locales to /usr/share/locale/ or add a config option pointing to the local checkout or what? I'm unsure how to deal with the php translations if we do the former.
Comment by Lukas Fleischer (lfleischer) - Saturday, 21 July 2018, 08:21 GMT
Maybe it makes sense to add a configuration option for additional locale search paths? That way, we could keep the location as-is for now and install them later without any additional code changes.

Loading...