• 0

    posted a message on Stop changing our code.

    I understand what it's doing, but almost every part of is undesirable to me.

     

    I don't actually want to use localization injection, ever: if performed on uploaded ZIPs, it essentially produces an untested addon release. Even if the localization code itself is correct (and for \n-containing keys, it recently wasn't), bad localization data can break string.format calls within the addon. In practice, this means that if I used localization injection, I'd have to upload a version as alpha, wait for a modified archive, download that, test it, and reflag the version as release. This seems more annoying than my current approach of exporting and verifying localization data prior to generating an archive locally.

     

    It would be nice if the token replacements could be turned off on a per-project basis. Failing that, it would be nice if the file processor task realized that it made no actual changes, and kept the original ZIP file instead of producing another version of it -- at least then the archive MD5 would be a clear indication of whether or not it changed anything.

     

    Posted in: WoW Sites Feedback
  • 0

    posted a message on Stop changing our code.

    It's a different project, with localization enabled (but not actually used in a way that allows Curse to substitute anything): I'm comparing https://wow.curseforge.com/projects/opie/files/2351980/download (md5: f3f3...) vs https://www.townlong-yak.com/opie/get/umber5 (md5: 1505...).

    Posted in: WoW Sites Feedback
  • 0

    posted a message on Stop changing our code.

    It still seems to recompress the uploaded ZIP rather than serving the original (even if no files inside the ZIP are changed), which results in mismatched archive MD5 across different download sources. This rather increases the amount of effort required to make sure that curse is still serving the actual code uploaded.

    Posted in: WoW Sites Feedback
  • To post a comment, please or register a new account.