CLI first, outline of maintainer.

[tatarize]

I found the typical methods to be excessively harsh. Some of these might require poboy implement them since they might not exist for a project. However this protocol should be gingerly enough to work for any translations projects. And it would be perhaps helpful to consider this sort of automation as a general solution to a general project.

1. After all other processes, go through and convert generate all .mo files every time.
2. Generate from sources and update the .pot file. (Do not merely replace, unless the file does not exist).
3. Any message string that does not exist in the .pot file should be obsoleted (commented out) and the same done for the .po files without changing the order.
4. Comments should be preserved (sometimes these are lost during obsolete, this should be avoided). Source comments for translation strings should migrate into the files seamlessly. Replacing comments drawn from the source. User comments from the .pot file for example should not be lost. Neither generation of strings from source nor obsolete and de-obsolete should break remove these.
5. Source file position comments should be updated but not in a way that changes the original typesetting, and which minimizes diff. If the source file comments are 3 to a line, the replacements should also be 3 to a line. But further if a new position is found it should be appended to the end.
6. Any new message not found in the .pot to be added to the end, and the same done for the .po files. Any message-str found to exist again and is no longer obsolete should be restored.
7. The update done in this fashion should largely preserve the original doc string of the original translations.
8. The update done in this fashion should not restructure the translation for entries that are not being changed.

---

The core idea is that generated sources template should be used to update the current .pot file such that it preserves most comments and structures in that current file and the parts that are updated are done so in a way to minimize the diff from the previous version. And the same should be the case in for the .po files themselves. A comment that does not derive from source and that is not autogenerated, if in the .pot file should be pushed into all .po files. A comment that does not derive from source and is not auto-generated in a .po file should be preserved between any amount of updates.

There are some processes that some folks might want that could perhaps be done as their own operations.

1. Sort the .pot files message strings according to some criteria.
2. Sort the .po files messages to occur in the same order as the .pot file.
3. Sort the source position tagged autogenerated entries.
4. Reflow the typeset of the autogenerated entries, n per line or length.
5. Fuzzy match obsolete entries. Marking the matches as fuzzy.

---

The philosophical goals here are as follows:

1. Preserve metadata information between updates. Information added in the .po file and .pot files is important and should be maintained.

2. Minimize diff. If you can update something in a way that changes files less, that method of updating should be prioritized. The higher diff methods should be their own directly requested methods.

I think I worked a lot of this stuff in poboy a bit but I was a bit more concerned about making a user interface, but I think if these methods were correctly established in a CLI they might be much easier to put into the GUI since they would require some additional procedure mapping.

[tatarize]

In theory rather than implementing all of these initially a subset which by definition is less destructive (and maybe less helpful) than the full set could be implemented. Namely we use poboy to do an extremely minimized version of these that meets the philosophy.

1. We check the generated sources and any item not found in the .pot file but is a generated source is added to the end of the .pot file.
2. We check the .pot file and any msgstr found in the .pot but not in the the .po files, is appended to the end of the .po file.
3. We generate all .mo files.

These are about the minimum set of changes we could do. We then should divide up the other functions in a much more highly specific way perhaps requiring users to specify each thing they want to happen explicitly. And then using that to automate things. The functionalities could then be explicitly set. So you'd have to specify "update-source-positions" and "sort-source-positions" "reflow-source-positions 3" "init br-br" "sort-po-by-pot" and a lot of other very minor functions or call an overarching command that does all of those things.