• 0

    posted a message on Alpha/Non-Alpha Repository Keyword Substitutions not working properly

    Still present as of december the 4th

    I just released a new version of OrderHallCommander and all alpha code is there. This is really non good.

    Released addon:

    --@alpha@
    	addon.version="1.6.0 Alpha"
    --@end-alpha@
    
    Should have been
    
    --[===[@alpha@
    	addon.version="1.6.0 Alpha"
    --@end-alpha@]===]
    
    This according to curse documentation
    Alpha Replacements
    These occur based on filetype, as they tend to tie into the comment system for the file.
    The insides aren't removed so that line numbers stay the same, they just cause them to be commented out.
    These occur from packages created not from tags, i.e. alpha packages.
    This is useful to put extra debugging information that you want your alpha testers to have, but don't want to appear in release versions.
    Lua
    --@alpha@ and --@end-alpha@
    Turns into --[===[@alpha and --@end-alpha]===].
    --[===[@non-alpha@ and --@end-non-alpha@]===].
    Turns into --@non-alpha@ and --@end-non-alpha@.
    Example:
    --@alpha@
    assert(everythingIsOkay())
    --@end-alpha@

     

     

    Posted in: WoW Sites Feedback
  • 0

    posted a message on [Request/Suggestion] Improve Navigation between CurseForge sites

    Guys, having the filter set to "all" makes no sense, no one wants to normally see their deleted/abandoned/unapproved projects, and changing a default should not take more than a few minutes.

    It would be appreciated

    Posted in: WoW Sites Feedback
  • 0

    posted a message on Issues with localization exporting during auto-packaging

    5. Localization for included libraries

     

    When you include via .pkgmeta a library which has been localized with curse, packager uses the localization data from the including addon EVEN for the library, so localizing via curse a library is right now impossible.

     

    I am afraid that packager is very very low in their priority, even if addon writers are their main asset (as the reward program prove)

    Posted in: WoW Sites Feedback
  • 0

    posted a message on Curse keyword substitution not applied for libraries

    Looks like tags are honored again BUT a new issue raised:

    Localization tags are pulling localization from the embedding addon, not from the embedded one.

    This makes localization unusable for libraries.

    You can check my addon OrderHallCommander

     

    The file libs/LibInit/LibInit.lua (pulled from LibInit) no longer ends with

    --@do-not-package@
    -- Packager stil not honoring this tag
    --@end-do-not-package@

     

    but when you check the file libs/LibInit/Localization.lua you see that it contains localization keys from OrderHallCommander, not from LibInit

    Posted in: WoW Sites Feedback
  • 0

    posted a message on Curse keyword substitution not applied for libraries

    Please, raise this issue priority, it's impacting all libraries developers

    Posted in: WoW Sites Feedback
  • 0

    posted a message on Curse keyword substitution not applied for libraries

    When you pull a library defining it in pkgmeta, the packager ignores all @something verbs

     

    This rendere, for example, useless the localization for libraries.

    This was working with the old packager.

    I already raised this bug but was told that behaviour was the same in old packager but this is not true. checked all zips and keyowrd substitution was managed for files pulled via pkgmeta

     

     

    Posted in: WoW Sites Feedback
  • 0

    posted a message on Are you guys still manually approving files?

    Mixed feelings: while I deeply appreciate and respect your dedication, I cant but ask what went wrong , because I am sure that manually fiddling with all uploaded files was not your plan A (nor the B one, probably).

    I also understand that you are quite busy right now, so never mind if you cant find time to answer this question.

     

    Kudos

     

     

     

    Posted in: WoW Sites Feedback
  • 0

    posted a message on Are you guys still manually approving files?

    By the way, Dashboard thinks all went well.
    I tried downloading the zip file, and it does not contain the localization file (localization.lua) at all, while all other files are present

    Log
    Date	Priority	Message	Revision
    1 hour ago	Low	Request completed.	--
    1 hour ago	Low	Completed revision: 08a6f695f199fd898f6826a99b7496e182e14791	08a6f695f199fd898f6826a99b7496e182e14791
    1 hour ago	Low	Processing revision: 08a6f695f199fd898f6826a99b7496e182e14791	--
    1 hour ago	Medium	Revision 76d33362c05958f7cb2a5f0f2c1be7b9920600e9 with tag 0.1.0-Beta6 has already been processed.	76d33362c05958f7cb2a5f0f2c1be7b9920600e9
    1 hour ago	Low	Processing revision: 76d33362c05958f7cb2a5f0f2c1be7b9920600e9	--
    1 hour ago	Low	Processing request. (attempt 1)	--

     

    Posted in: WoW Sites Feedback
  • 0

    posted a message on Are you guys still manually approving files?

    So far it's 1 hour, so I suppose this escalates to "Packager is broken"

     

    Posted in: WoW Sites Feedback
  • 0

    posted a message on Are you guys still manually approving files?

    Because 42 minutes (and counting) "Under review" is a hell of a time for a computer :)

     

    Posted in: WoW Sites Feedback
  • 0

    posted a message on Localization escape-non-ascii

    As a side note, maybe you could make "escape-non-ascii" a nop for World of Warcraft, because as far as I know it's both broken and useless.

    Removing it fixes localization data

    Posted in: WoW Sites Feedback
  • 0

    posted a message on Localization export bug (multiline phrases)

    Confirmed, it's working now:

    L[ [=[Configures REQUESTS.
     Set what each toon needs]=] ] = true

     This is valid lua, now!

    Thank you guys

    (Now, if we only could have back the old syntax highlighter in the forum... that would be awesome)

     

     

    Posted in: WoW Sites Feedback
  • 0

    posted a message on Localization export bug (multiline phrases)

    Hi Torhal, actually I waited for it to be in the "approved" status, because I already noticed that in the "new" and in the "Under review" status localization is not yet ready (and it is absolutely logical too).

     

    Now, it's localized.

    Maybe you can check if the "approved" status is granted a bit too early.

    Very often I tag alphas to check i did not messed something in pkgmeta or forgot a keywors substitution tag open, so I download it as soon as possible and the remove it because I dont want any user having it.

    Knowing for certain when Curse is done packaging would be helpful (actually, the preferred solution would imho not to show the file at all until it's ready)

     

    Now, we only miss the fix for the multiline keyboard and we will be good to go

    Posted in: WoW Sites Feedback
  • 0

    posted a message on Localization export bug (multiline phrases)

    Also, in packages tagged as "Alpha" localization is not filled: 

    local L=l:NewLocale(me,"enUS",true,true)
    --@localization(locale="enUS", format="lua_additive_table" , escape-non-ascii=true, same-key-is-true=true, handle-unlocalized="blank" )@
    L=l:NewLocale(me,"ptBR")
    if (L) then
    --@localization(locale="ptBR", format="lua_additive_table" , escape-non-ascii=true, same-key-is-true=true, handle-unlocalized="blank" )@
    return
    end
    L=l:NewLocale(me,"frFR")
    if (L) then
    --@localization(locale="frFR", format="lua_additive_table" , escape-non-ascii=true, same-key-is-true=true, handle-unlocalized="blank" )@
    return
    end
    L=l:NewLocale(me,"deDE")
    if (L) then
    --@localization(locale="deDE", format="lua_additive_table" , escape-non-ascii=true, same-key-is-true=true, handle-unlocalized="blank" )@
    return
    end
    L=l:NewLocale(me,"itIT")
    if (L) then
    --@localization(locale="itIT", format="lua_additive_table" , escape-non-ascii=true, same-key-is-true=true, handle-unlocalized="blank" )@
    return
    end
    L=l:NewLocale(me,"koKR")
    if (L) then
    --@localization(locale="koKR", format="lua_additive_table" , escape-non-ascii=true, same-key-is-true=true, handle-unlocalized="blank" )@
    return
    end
    L=l:NewLocale(me,"esMX")
    if (L) then
    --@localization(locale="esMX", format="lua_additive_table" , escape-non-ascii=true, same-key-is-true=true, handle-unlocalized="blank" )@
    return
    end
    L=l:NewLocale(me,"ruRU")
    if (L) then
    --@localization(locale="ruRU", format="lua_additive_table" , escape-non-ascii=true, same-key-is-true=true, handle-unlocalized="blank" )@
    return
    end
    L=l:NewLocale(me,"zhCN")
    if (L) then
    --@localization(locale="zhCN", format="lua_additive_table" , escape-non-ascii=true, same-key-is-true=true, handle-unlocalized="blank" )@
    return
    end
    L=l:NewLocale(me,"esES")
    if (L) then
    --@localization(locale="esES", format="lua_additive_table" , escape-non-ascii=true, same-key-is-true=true, handle-unlocalized="blank" )@
    return
    end
    L=l:NewLocale(me,"zhTW")
    if (L) then
    --@localization(locale="zhTW", format="lua_additive_table" , escape-non-ascii=true, same-key-is-true=true, handle-unlocalized="blank" )@
    return
    end
    

     

    Posted in: WoW Sites Feedback
  • 0

    posted a message on Packager BUG
    Quote from ZeldoKavira >>
    Quote from alar >>

    In files pulled in via pkgmeta externals, keyword substitition is not working

    All debug code is released and even do-not-package is not honored

     

     This is the same as the old packager, we have a ticket in to improve this but it is currently on par with the old.
    Quote from oscarucb >>

    #@no-lib-strip@ in TOC files is also being ignored, breaking no-lib creation.

     

    Is there a new syntax for no-lib exclusion? (it does not appear in the new packager docs)

     I am adding a ticket for this now, should still be the same. 
    Quote from arith >>

    previously before the migration, the keyword replacement handles the "do-not-package" properly.

    for example, the entire block enclosed by "--@do-not-package@" and "--@end-do-not-package@" will be removed after auto-packaging.

    Now after the migration, everything enclosed by those two tags will be removed except the ending tag.

    Means the "--@end-do-not-package@" is still there.

    Although this is no harm to the function, but still a bug.

    We have a ticket for this but due to other tickets being higher priority it has not been completed yet. 
     This is simple not true
    Old packagee was doing it in the right way (Garrison Commander 2.15.0, LibInit pulled via pkgmeta external)
    --[===[@debug@
    LoadAddOn("LibDebug")
    LoadAddOn("Blizzard_DebugTools")
    if LibDebug then
    	--pulling libdebug print in without pulling also the whole _G management and without changing loading addon env
    	LibDebug()
    	dprint=print
    	setfenv(1,_G)
    end
    --@end-debug@]===]

    Now for the same code  I had to manually comment out because --@debug@ substitution no longer works (Garrison Commander 2.15.8)

    --@debug@
    --LoadAddOn("LibDebug")
    --LoadAddOn("Blizzard_DebugTools")
    --if LibDebug then
    	--pulling libdebug print in without pulling also the whole _G management and without changing loading addon env
    --	LibDebug()
    --	dprint=print
    --	setfenv(1,_G)
    --end
    --@end-debug@
    <br /><br />

     

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