These are chat archives for chocolatey/ChocolateyGUI

22nd
May 2018
Manfred Wallner
@mwallner
May 22 2018 18:14
hey @ferventcoder @gep13 @punker76 - I've had some trouble building Choco GUI at work today - turns out we've got the nuget repositoryPath key (https://docs.microsoft.com/en-us/nuget/reference/nuget-config-file) changed to a fixed location so that all dependencies exist only once on a machine. (actually makes sense with very big workspaces that have a lot of dependencies) - sadly all nuget refs in choco gui seem to be relative to the csproj file. would a PR that changes all these refs to utilize $(NUGET_PACKAGE_ROOT)? / actually this seems to be buggy somehow - any experience with that?
Gary Ewan Park
@gep13
May 22 2018 18:17
@mwallner assuming we can get something that works for both the default location, and your location, I would have no objections.
Manfred Wallner
@mwallner
May 22 2018 18:21
great! :-)
Manfred Wallner
@mwallner
May 22 2018 18:54

well, for most of the packages it just works when I drop the <hintpath> - but as soon as I reached

 <Import Project="..\packages\cef.redist.x64.3.2987.1601\build\cef.redist.x64.targets" Condition="Exists('..\packages\cef.redist.x64.3.2987.1601\build\cef.redist.x64.targets')" />

things got complicated :-( ... any Idea how this could be resolved?
my global nuget config (C:\Program Files (x86)\NuGet\Config\NuGet.Config) now contains:

  <config>
    <add key="repositoryPath" value="c:\nugetglobal" />
  </config>
Manfred Wallner
@mwallner
May 22 2018 18:59
maybe I'll just write a PowerShell "buildscript" that temporary disables that global nuget config :-D - this way I can work with the defaults ... problem solved xD
Gary Ewan Park
@gep13
May 22 2018 19:00
Short answer is, I don't know of an "easy" way of doing what you are asking, unless....
Does it still create a packages folder within that c:\nugetglobal\ folder?
Manfred Wallner
@mwallner
May 22 2018 19:01
nope, sadly not
Gary Ewan Park
@gep13
May 22 2018 19:02
In which case, I don't have any good suggestions
Short of adding an additional Import statement, that is specifically checking for the existence of the c:\nugetglobal folder
but that feels....
dirty
If you had an environmental variable on your machine, that stored that location, we could use that
Manfred Wallner
@mwallner
May 22 2018 19:03
... dislike all of that ....
I'll just
Move-Item "C:\Program Files (x86)\NuGet\Config\NuGet.Config" "C:\Program Files (x86)\NuGet\Config\NuGet.Config.backup"
try {
    cake build magic
}
finally {
     Move-Item "C:\Program Files (x86)\NuGet\Config\NuGet.Config.backup" "C:\Program Files (x86)\NuGet\Config\NuGet.Config" 
}
on my PC at work, - that should be sufficient for the couple of "beta-builds" I'll need to do there ..
Gary Ewan Park
@gep13
May 22 2018 19:04
okay, sounds like a plan :+1:
Manfred Wallner
@mwallner
May 22 2018 19:05
btw, I've updated a couple of translations in transifex - when do they get pulled in? / any chance I can translate the resouces for a PR before it gets merged?
Gary Ewan Park
@gep13
May 22 2018 19:06
The updated transifex files are pulled on each build I believe. They might not be for a PR, but certainly once that PR is merged, they would be pulled in.
Manfred Wallner
@mwallner
May 22 2018 19:08
ok, so there isn't a way to translate a resource in advance? (so it would already be present at the time the PR gets merged) / transifex always/only works on resources in the develop branch?
Gary Ewan Park
@gep13
May 22 2018 19:10
I am not sure that I follow exactly what you mean.... Let me try to explain the workflow, to see if it helps answer your question.... The only resource that is checked into source control is the original english translation. During the build process, we request the additional resx files directly from transifex that have all the translations that have been completed. These are then placed onto the file system, and included into the generated binary that is Chocolatey GUI. These files are not checked into source control, they only exist as part of the build.
Does that help answer your question?
What exactly are you wanting to do?
Manfred Wallner
@mwallner
May 22 2018 19:15
umm.. ok - I've been working on this: chocolatey/ChocolateyGUI#591 - which adds a new string (configuration option) to the settings page - so there'll be a new resource string to translate - this PR will merge the branch searchallrepo (in which the new string exists) into the develop branch (in which the string does not exist) - in transifex I don't see the new resource as long as the PR hasn't been processed - so there will always (each time a string is added to the resouces to be exact) be missing translations when pulling in PRs
I'd like to be able to translate the newly added string SettingsView_SearchInAllRepos before the PR gets merged - so a German translation would be there from the beginning
Gary Ewan Park
@gep13
May 22 2018 19:17
Ah, I see what you mean. In which case, yes, there is a slight chicken and egg situation going on here. Your PR would add the string to the default resources file. During the "sync" with Transifex, this updated resx file would be pushed to transifex, which would allow you to provide the german translation. From there, you would then need to wait for another build to grab that translation, to add it into the application
Manfred Wallner
@mwallner
May 22 2018 19:18
yup that's what I was talking about
Gary Ewan Park
@gep13
May 22 2018 19:18
ok, so we are on the same page :-D
Manfred Wallner
@mwallner
May 22 2018 19:18
could this be split into a "pre-build" and "build" ?
Gary Ewan Park
@gep13
May 22 2018 19:19
Not sure that there is much that we can do about that, unless we manually uploaded the modified resx file
I would need to consult with @AdmiringWorm on the "best practice" here though
Manfred Wallner
@mwallner
May 22 2018 19:19
so after a "pre-build" a @ all message is sent here in gitter to all translators, stating idk "in 2 days there'll be a release, please update the translations if possible" - and then build?
Kim J. Nordmo
@AdmiringWorm
May 22 2018 19:24
with the current flow, I don't believe it would be possible to add new strings for the languages until the PR have been merged.
Well not without potential issues anyhow.
What would be needed is to check in the Resources.resx file for the language that needs to be updated, but it would need to be kept in sync with transifex before being pushed there (otherwise untranslated entries in that Resources.resx would delete the translations on transifex, I think). The build script would also need to be updated to support that scenario though.
The safest bet for now, would be to just keep a local copy of the strings you want to translate, and when the PR is merged then add it on transifex
@mwallner ^^
Manfred Wallner
@mwallner
May 22 2018 19:25
well that's ugly - but ok ^^
but yes .. I get that having that dependency on the translation service introduces another "level of complexity" that is best kept low by just "running multiple builds"
thanks for talking about the issue anyway :-)
Gary Ewan Park
@gep13
May 22 2018 19:27
Another solution would be to create a small PR, which only adds the entry to the resx file
That could be merged immediately
and then your other PR could build on that
Manfred Wallner
@mwallner
May 22 2018 19:28
oh right! :-) I think I'll just split up future PRs into "Resource PR" -> "implementation PR" if that's ok for you
Gary Ewan Park
@gep13
May 22 2018 19:29
Sounds fine to me
@AdmiringWorm thoughts?
Kim J. Nordmo
@AdmiringWorm
May 22 2018 19:30
yeah, that sounds fine for me as well
Gary Ewan Park
@gep13
May 22 2018 19:31
:+1:
So only thing that we will have to remember here is that if an implementation PR doesn't get pulled in for some reason, then we would need to remove the addition to the resx, but I think that is OK to have to do
Kim J. Nordmo
@AdmiringWorm
May 22 2018 19:36

well that's ugly - but ok ^^

While I do agree, consider it like this.
Transifex is expected to always have the latest translations, so the translated resource files more or less just gets replaced when pulling it down.
Now, if you push out a translated resource file this should now considered the latest edition. When a entry in that resource file is untranslated, then why is that? Perhaps it was an incorrect translation, a better translation is being worked on but not yet ready, or something completely different. Of course, there could be an option somewhere that I've forgotten that only considers translated non-empty entries in a resource to be updated, but I'll need to look into that then.

So only thing that we will have to remember here is that if an implementation PR doesn't get pulled in for some reason, then we would need to remove the addition to the resx, but I think that is OK to have to do

@gep13 I would probably consider that a lesser evil in these cases. Of course, could be easy to forget though

Gary Ewan Park
@gep13
May 22 2018 19:38
Yeah, agreed. It isn't a HUGE deal, in the sense that it would be a translation, that isn't being used, so it wouldn't impact on anything
Kim J. Nordmo
@AdmiringWorm
May 22 2018 19:38
true
Manfred Wallner
@mwallner
May 22 2018 20:22
darn .. I forgot - we do usually NOT assign labels to PRs .. right?