The exported GPX files are saved to the application documents directory but are never cleaned up (the cleanup code is commented out at line 158). Over time, this could accumulate many files and consume storage space. Consider implementing automatic cleanup of old export files, or at least uncomment the file deletion after successful sharing.

Redundant null-coalescing operator. The code already checks if latitude/longitude are null on the previous lines (52-54), so when adding the contact on lines 57-58, the null-coalescing operator (?? 0.0) will never be used. Either remove the redundant check on lines 52-54 and rely on the null-coalescing, or remove the null-coalescing operators as they serve no purpose after the null check.

The variable name 'repeaters' is misleading when filtering for 'advTypeChat' contacts. This method is supposed to add contacts (chat users), not repeaters. The variable should be named 'contacts' or 'chatContacts' to accurately reflect what it contains.

The share text says 'Repeater locations' but this export can be used for repeaters, contacts, or all entities. The share text should be more generic to accurately describe what's being shared in all use cases.

The GPX creator is hardcoded as 'meshcore-open Repeater Exporter' but this export is used for more than just repeaters (also chat contacts and all entities). Consider using a more generic creator name like 'meshcore-open Contact Exporter' or 'meshcore-open'.

The variable name 'repeater' is misleading when iterating over chat contacts (advTypeChat). Since this method filters for chat contacts, the iteration variable should be named 'contact' or 'chatContact' to match its actual type.

The variable name 'repeater' is misleading when iterating over all contacts. Since this method processes all contact types (including chat, repeater, room, and sensor types), the iteration variable should be named 'contact' to accurately reflect what it contains.

The metadata description says 'Repeater & room locations' but this export can also include chat contacts (via addContacts) or all contact types (via addAll). The description should be more generic like 'Contact locations exported from meshcore-open' to accurately reflect all use cases.

The share_plus package API usage appears to be incorrect for version 12.0.1. The standard API in share_plus v12 is 'Share.shareXFiles([XFile(...)])' rather than 'SharePlus.instance.share(ShareParams(...))'. The ShareParams and SharePlus.instance pattern is not part of the standard share_plus API. Please verify the correct API usage for share_plus v12.0.1 and update accordingly.

This deprecated and is not valid.

The filename contains 'meshcore_repeaters_' but this export function is also used for exporting chat contacts and all entities, not just repeaters. Consider making the filename more generic like 'meshcore_contacts_' or making it configurable based on what is being exported.

Since this repo commits pubspec.lock and CI caches/builds using it, adding new direct dependencies here should be accompanied by an updated pubspec.lock. Also, share_plus appears in the Windows/macOS registrants but not in Linux/iOS project files in the repo; ensure the platform plugin registrants are regenerated/committed consistently so desktop/mobile builds register the plugin everywhere.

Typo in the exported filename base: meshcore_reapters should be meshcore_repeaters (this affects the actual GPX filename generated for English locale).

The Bulgarian translations contain mixed Cyrillic/Latin text (изlexport), which appears to be an accidental placeholder/typo and is user-facing. Please replace with proper Bulgarian wording (pure Cyrillic).

The switch over result is missing terminating statements (break/return/etc.) for each case. In Dart this is a compile-time error, and it also means you can’t add handling for gpxExportCancelled (which exportGPX can return). Add break/return for each case and include an explicit case for gpxExportCancelled (even if it’s a no-op).

This file imports dart:io and uses File, but the project’s CI builds flutter build web; importing dart:io will fail web compilation. Split the implementation via conditional imports (IO vs web), or move the IO-specific code behind a platform-specific file and provide a web-safe stub that returns gpxExportNotAvailable (or implements a browser download/share).

I don't know if we explicitly support web at this time

'${dir.path}/$filename\_$timestamp.gpx' contains \_, which is an invalid escape sequence in Dart strings (it won’t compile). You don’t need to escape _ here—remove the backslash (and the ignore).

Without it, it thinks it part of the var name.

'${dir.path}/$filename\_$timestamp.gpx' contains \_, which is an invalid escape sequence in Dart strings (it won’t compile). You don’t need to escape _ here—remove the backslash (and the ignore).

Without it it think it part of the var name.

'${dir.path}/$filename\_$timestamp.gpx' contains \_, which is an invalid escape sequence in Dart strings (it won’t compile). You don’t need to escape _ here—remove the backslash (and the ignore).

The GPX metadata name passed to the exporter uses l10n.map_repeater, which will label the exported file as “Repeater” even though this action exports repeater+room locations. Consider using a GPX-specific label (e.g. settings_gpxExportRepeatersRoom or settings_gpxExportRepeaters) so the shared file metadata matches its contents.

The GPX metadata name passed to the exporter uses l10n.map_repeater, which will label the exported file as “Repeater” even though this action exports all contacts. Use an “all contacts” label so the GPX metadata matches the export.

The log message says "No repeaters to export" but this exporter is also used for contacts/all exports. Update the message to something generic like "No contacts to export" to avoid misleading logs.

same thing

The usage header and examples refer to translate_arb_with_ollama.py, but the file in this repo is tools/translate.py and there is no translate_arb_with_ollama.py. Update the docstring/examples (or rename the file) so the documented command actually works.

This PR is described as adding GPX export, but it also includes a large unrelated rewrite of tools/translate.py. Consider splitting the translation tooling changes into a separate PR to keep scope focused and reduce review/merge risk.

The Bulgarian translation contains the non-word “изlexport” (mixed Cyrillic/Latin), which looks like a generation artifact. Replace it with proper Bulgarian (e.g. use “експортиране” consistently).

Variable full_match is not used.

Variable preserve_list is not used.

'except' clause does nothing but pass and there is no explanatory comment.

This statement is unreachable.

I don't know if we explicitly support web at this time

agreed, however it's just a debug print

same thing

In this switch, the gpxExportSuccess case doesn’t end with break/return, which makes the switch invalid in Dart (cases can’t fall through). Add a break (or return) after showing the success SnackBar; also ensure the other cases are still reached correctly.

If writeAsString or share(...) throws, the GPX file is never deleted because file.delete() is only reached on the success path. Consider moving cleanup into a finally block (and optionally swallowing delete errors) so temporary exports don’t accumulate and a successful share isn’t reported as failed due to a cleanup exception.

This debug log is shown when _contacts is empty, but it hard-codes “No repeaters to export” even when exporting chat contacts or “all”. Update the message to be generic (e.g., “No contacts to export”) so diagnostics match the selected export type.