Extend the generated gitignore.

[HolonProduction]

To match the ignore file described in the docs.

As #42392 was not merged .translation files still need to be ignored.

I am not using the Mono version but as far as I can tell from source code the .mono folder is now located inside .godot so there is no need to ignore it. If someone could confirm this I can change the documentation as well.

[RedMser]

I am not using the Mono version but as far as I can tell from source code the .mono folder is now located inside .godot so there is no need to ignore it. If someone could confirm this I can change the documentation as well.

This is correct.

[aaronfranke]

Indeed with #42392 the goal was to move these inside of .godot/ since they are generated, but since that hasn't been done then yet it makes sense to put it in the .gitignore file.

For export_presets.cfg, IIRC the goal was to stop putting sensitive information in that file so that it can be committed to version control. What's the status of this? CC @godotengine/android.

For .mono/, indeed it should not be included, and we should remove that bit from the docs.

[BastiaanOlij]

I would also add android/build and android/.build_version but leave out android/plugins so developers who are using the gradle android templates don't get their whole build cache checked in.

That said, that may need further input from the android team as there may be certain files in the android/build folder we want to retain.

[HolonProduction]

Since I opened this the android and export template thematic has been resolved. I updated the PR to only add *.translation files to the gitignore.

[HolonProduction]

The change is still in line with the current documentation. What exactly is blocking this?

[akien-mga]

I'm still in doubt that this documentation is accurate.

.translation files are quite special in that they are a mapping of a single source file to multiple imported resources. This is also partly why they're not in .godot/imported/ because they don't match the usual pattern of one-to-one but are one-to-many. They're also selected explicitly in the Project Settings localization tab, which again is quite different from regular imported files which aren't visible to the user.

I'd appreciate insights from @timothyqiu or @bruvzg on the translation system to see if it's indeed safe to treat those as files to re-generate on the fly.

[bruvzg]

.translation files are regenerable, and it should be safe to delete them (editor will print a few errors when project first opened, and recreate them).

This is also partly why they're not in .godot/imported/ because they don't match the usual pattern of one-to-one but are one-to-many.

I guess the main reason for it, these files can be individually selected in the project settings (instead of selecting source file as it usually works).

[timothyqiu]

AFAIK, .translation files can indeed be generated on the fly, but the main issue arises during the editor's initial startup.

ResourceLoader currently attempts to re-import the resource if loading fails on the first run. However, since .translation files are usually not imported from itself (but from a separate csv file), this initial import will fail. Consequently, references may become broken if others reference them on editor start.

[HolonProduction]

ResourceLoader currently attempts to re-import the resource if loading fails on the first run. However, since .translation files are usually not imported from itself (but from a separate csv file), this initial import will fail. Consequently, references may become broken if others reference them on editor start.

I read that as it's not safe to regenerate them. So I'd suggest updating the docs instead of this PR.