Skip to main content
Explore documentation

Find logs and report errors

Collect the version, steps, and relevant log excerpt so a problem can be investigated without sharing unnecessary private information.

Guide based on source version 2.0.1-rc.7. Screenshots show the English interface of a prerelease edition; their values illustrate examples, not necessarily defaults. Packages on Downloads may differ: review their release notes and saving options before processing.

On this page

Find the log

Yagua attempts to write yagua.log in your user preferences folder:

SystemPath
Windows%APPDATA%\Yagua\yagua.log
Linux~/.config/Yagua/yagua.log
Experimental macOS~/Library/Application Support/Yagua/yagua.log

Windows: paste %APPDATA%\Yagua into File Explorer’s address bar, then open yagua.log with a text editor.

Linux: open ~/.config/Yagua in your file manager; you may need to show hidden files. ~ means your home folder. You can also read the path from a terminal without modifying the file:

tail -n 100 ~/.config/Yagua/yagua.log

There is no accessible Settings → Logs button or menu in this edition. Read the log through the filesystem. If the user profile is not writable, the app may continue without an on-disk log.

Prepare a useful case

  1. Record the installed package’s full version, including rc when present. Use the installer, AppImage, or portable archive name and its release notes; the pictured Updates screen has no Current version field. State explicitly if you cannot confirm the version.
  2. Record the system, architecture, installation type, and package download source.
  3. Reproduce the problem with a small copy without private data.
  4. Note the time and exact message.
  5. Find the log lines from that time and the preceding context that identifies the active tool.

The file accumulates entries. You do not need to send its entire history if the relevant excerpt identifies the failure. Date and time help identify the right operation.

Review before sharing

Logs can contain full paths, filenames, library errors, and coordinates related to your work. Screenshots can also reveal private images. Review the material, hide sensitive details in a copy, and keep the error structure needed to understand the problem.

Do not share passwords, tokens, or configuration files unrelated to the issue. Do not publish someone else’s images or personal documents just because an example is requested. Prepare a sample that reproduces the error without exposing them.

Report template

Open an issue in the project tracker and include the following where relevant. The copyable template keeps the original field names:

Versión de Yagua:
Sistema y arquitectura:
Paquete: instalador / portable / AppImage / código fuente
Módulo y pestaña:
Idioma, tema y escala de interfaz:
Formato, dimensiones y número de imágenes:
Opciones utilizadas:
Pasos para reproducir:
Resultado esperado:
Resultado real y mensaje exacto:
¿Sucede con una muestra sin datos privados?:
Fragmento de yagua.log y hora del fallo:

Record the Yagua version, system and architecture, package type, tool and tab, interface language/theme/scale, input format/dimensions/count, settings, reproduction steps, expected and actual behavior, exact message, whether a private-data-free sample reproduces it, and the log excerpt with its time.

For an AI-related issue, say whether it was the first run, whether a connection was available, and which OCR language you chose. For export errors, say whether the output already existed and whether the folder was writable. For a startup failure without a log, include the system error and how you tried to open the package.

Example of concrete steps

“Open Convert; select an 800 × 600 PNG; choose WEBP and quality 85; click Convert; select a writable folder; message X appears” is more useful than “conversion fails.”

Do not assume every file failed when results are partial. Include how many were selected, how many were saved, and the formats of failed files.