There were two problems with this:
1. If the starting offset was beyond the end of the disc,
we would dereference an invalid iterator.
2. The data beyond the end of the disc was non-deterministic.
Having DiscContents with size 0 would mean that some DiscContents
might not get added to the std::set because of them comparing
identically to another DiscContent.
This replaces an older piece of code in WriteDirectory that ensures
that no two files have the same starting offset. (We now care about
the ending offset, not the starting offset. The new solution both
ensures that no two files have the same ending offset and that no
two files have the same starting offset.)
When building DolphinWX using cmake, msgmerge will run on the
.po files, updating the formatting of them if they aren't
already in the exact format that msgmerge uses. This means that
running msgmerge on all the .po files is necessary before
committing any updates to the .po files, because otherwise
unstaged changes are going to appear whenever anyone tries to
build that commit using cmake. The translation syncing scripts
that were used by delroth and Parlane did so by invoking `cmake`
and then `make translations`, but that isn't a good solution
for people who sync translations on Windows (i.e. me).
This commit uncomments some existing code for running msgmerge
on all the .po files, and places that code in a new script. Now,
translation syncing scripts just have to call that script before
committing, instead of using msgmerge directly or using cmake.
I'm not sure why the script was called gettextize to begin with.
gettextize is the name of a gettext executable that doesn't seem
to be related to what our gettextize script did.
For instance, we don't want to show TGC files that might be
inside the /files/ directory of a GameCube DirectoryBlob,
and we don't want to show the /sys/main.dol files for extra
partitions of Wii DirectoryBlobs.
Now it's clearer that SetDOL depends on SetApploader
and BuildFST depends on SetDOL.
As a side note, we now load the DOL even if there's
no apploader. (I don't think it matters whether we
do it, but it was easier to implement this way.)
Leo Lam