Gettext works beautifully in development.
When pushing to a staging environment, a debian machine, translation are pushed, the plug runs, but no translations are loaded?
The custom plug does read the accept language header properly:
sv-SE,sv;q=0.8,en;q=0.5,en-US;q=0.3
It converts it into sv_se which matches what's in .po files
msgid ""
msgstr ""
"Language: sv_se\n"
"Plural-Forms: nplurals=2\n"
Any clues?
It doesn't matter if I run
MIX_ENV=prod mix phx.server
or just
mix phx.server
on the debian machine. Still not showing translations regardless.
feeling lost & confused * - don't know where else to look.
Found it.
The folder name is meant to be sv_se.
On staging it was sv_SE.
It was sv_SE from the beginning, but with all the different ways browsers indicate accept-language I figured sticking to all lowercase would in general make the entire process more managable.
I guess git just ignored the change of the folder name to all lowercase.
Update:
I also had to add: git config core.ignorecase false on my osx-development machine, to ensure future commits would also be pushed to sv_se on staging.
Related
I uploaded my Laravel project to a shared server, now I am trying to clone the project from a local computer and I am getting the following error:
error: invalid path 'public/C:\xampp\htdocs\pfuxelacolab\storage\logs/laravel.log'
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'
Help Please...
You have a repository with a commit that you, personally, cannot use on your system. A Linux user can use this commit, but you can't.
The problem here is the file's name:
public/C:\xampp\htdocs\pfuxelacolab\storage\logs/laravel.log
In a Git commit,1 there are no folders: files simply have long names like this one. Each forward slash / in a committed file's name—and only the forward slashes—will, on a Windows system, be turned into the appropriate backwards slash \ and Git will break up the path into pieces such as public and laravel.log and so on.2 Git will then do what your OS demands: treat each of the various pieces as folder-and-file parts, and make any folders needed so that it can create your OS's idea of a file named laravel.log in your OS's idea of a folder. Git itself doesn't hold with such silly notions: you just have a file with a long name with forward slashes in it, but OSes have these dumb and silly folder-and-file requirements, so, okay, Git will deal with it.
In any case, this file's name includes C: right in the middle—not up front, where some DOS/Windows software might be able to deal with it, but in the middle, after public. So Git is trying to create a new folder, named either C: or C:\xampp\htdocs\pfuxelacolab\storage\logs, within a public folder, and that is never going to work: Windows says you can't do that. Linux, by contrast, says Oh you'd like to create that as a folder name? Sure, done!
So, someone on a Linux or similar system can check out this commit. Having done so, they can fix the file's name or remove the file entirely and make a new commit that doesn't have this bizarro name with the colon and backslashes inside it. Remember, Git demands forward slashes. It will make forward slashes for its own commits, from the OS's folders and files. But it will also take any file names with embedded colons and backslashes found on a Linux system, and make a commit from those, that can't be extracted on a Windows system. That's what someone did: they created a folder named C:\xampp\htdocs\pfuxelacolab\storage\logs in a folder named public, and created a file named laravel.log in that, and then added that to Git's index and committed it, presumably on a Linux system.3
The easiest way for you to deal with this will be to boot up a Linux system (perhaps in a VM) and check out the commit in question and make a corrected one to use instead. Whether you can do this at all in WSL, I have no idea.
1Technically, this claim is true not of the commits themselves, but of Git's index. But commits move "through" the index on the way out to your working tree, and are made from the index, so the condition applies anyway.
2Since I don't use Windows, I don't know whether Git will try to break apart the backslashed pieces here too—but it won't matter because of the C: part. It would be interesting to create a file named test\path/file on a Linux system, commit it, and try to check that commit out on Windows, though. Does Windows Git make a test folder? If not, does it (whether intentionally or merely accidentally) use an existing test folder and make a path folder? But Windows forbids colons in path names, and the embedded C: part, with or without any subsequent part, is the first and fatal problem here.
3While I keep saying "Linux" here, any OS that allows this will suffice, so Solaris or one of the BSDs would do the trick too. You could even do this on macOS.
On my windows machine I'm considering setting autocrlf = true in my .gitconfig. Others on my team have it set this way and we've ended up with a mix of lf & crlf in the repo. I've considered a few options and this seems like the path of least resistance...
One thing I've noticed is that git checkout -p fails with the error patch does not apply when autocrlf = true. If I change it back to false it works as expected.
Is autcrlf = true incompatible with checkout --patch or is do I need to set some other option to get it to work?
Interestingly git add --patch works as expected with autocrlf = true.
Yes, git checkout --patch works properly with line ending translation. The patch almost certainly isn't applying because you have mismatched configuration.
Everybody on your team needs to use the same line ending configuration. core.autocrlf=true isn't an option that one person on a team can enable; everybody needs the same settings. That's because if you have core.autocrlf=false, then you're telling Git that the contents on disk are identical to the contents in the repository. If you're on Windows, that means that you're checking in files with Windows-style line endings (\r\n). If you have a colleague who enables core.autocrlf=true, then you're telling Git that the contents on disk have Windows-style line endings while the contents in the repository have Unix style line endings (\n).
But your colleague has told git a lie, since the repository contents actually have \r\n in them.
A variety of strange things can occur when these settings are mismatched, including things like patches failing to apply.
You should instead:
Set * text=auto in your .gitattributes file. This ensures that everybody working in the repository has the same settings, since the configuration is actually checked in and not something that everybody has to remember to configure properly.
Renormalize the repository, so that the repository contents actually match what you've claimed. You can do this by git add --renormalize . and checking the contents in.
Once you've done this (and everybody has updated your local working folders), your git apply --patch should behave correctly.
I am using git in cli to change the current branch:
git checkout dev
and it produces:
fatal: cannot create directory at 'app/src/androidTest/java?com': Illegal byte sequence
As answered in this question and this one, I tried:
LC_ALL=C git checkout dev
or
LC_CTYPE=C git checkout dev
but I am getting the same error as shown above.
Running:
git status
shows that some of the files were changed by the checkout, but I am still on the master branch.
How can I remove the file causing the problems or how can I checkout the branch without getting this error?
The locale only affects how things are displayed. If the file name contains a character which isn't allowed by the file system, no amount of locale tweaking can fix that.
I can't think of a way to force a file system to let you create a file which then cannot be used, or a good reason to want to be able to do that.
Probably as a workaround, create a virtualized host with a bare-bones Linux system formatted to permit old-style 8-bit file names (Latin-1 or CP1252 if you can live with the unsavory Windows flavor of that), check out the file there, rename and commit the rename back to git. You still won't be able to check out versions of the source tree from before the rename.
I have found a few files in various github projects that are not compatible with one or another operating system. Files with a ".nul" or ".con" extension are a real pain on windows, for example. It isn't a problem exclusive to git. For example Subversion will abort nastily if it can't restore a file for local naming reasons.
In some cases the file may have been uploaded in error. If that is the case for your own projects it should be possible to use the git tools to list the archive and perform a delete of the file from the archive without actually instancing the file locally.
In other cases perhaps that particular file is not significant, and perhaps can be ignored. Perhaps a test will fail if it is missing?
One trick I have used is to stop the whole folder containing that file from being synced by manually creating the directory path, but for the last element, create an empty file instead of a folder. Of course, now the whole test suite will fail.
When the version control tries to do the checkout, it will simply fail to restore the folder, rather than giving a fatal error.
Of course, that only works if the folder is non-critical, e.g. some test files.
The alternative is to piecemeal check-out all but the problem file, but that can be a tedious sequence of checkouts. But you can use this attack to restore the rest of the folder that you omitted using the above technique. Alternatively, locally drag the files from the zip download if they are non-critical.
When I macfusion into my ubuntu VM, and hg clone something from bitbucket - and then try and do a commit / export / etc on it, I get a folder added with a name prefix of 'hg-checklinks-'.
On inspection it appears to house a never ending chain of symlinks back to its parent folder. This is driving me completely nuts, and so far, I've lost my faith in mercurial.
Mind you, seems to work fine when I just use it on a local folder. Does anyone have any idea how I can get around this.. or even more info as to why it's happening?
Cheers!
The decentralized part of DVCS is about running it locally -- the only Mercurial operations that should be done on anything other than the local system are push, pull, and clone. If you're cloning from bitbucket onto your Ubuntu VM then you should clone from your Ubuntu VM onto your mac and push to the Ubuntu VM.
That said, it looks like your network FS isn't correctly deleting the file when it's told to. Here's the relevant code (found here: https://www.mercurial-scm.org/repo/hg/file/a2dc8819bb0d/mercurial/util.py#l710):
name = tempfile.mktemp(dir=path, prefix='hg-checklink-')
try:
os.symlink(".", name)
os.unlink(name)
return True
except (OSError, AttributeError):
return False
So either your network FS is creating the symlink but throwing an exception anyway or throwing an exception when asked to delete (unlink) the symlink.
The problem here is with sshfs's very special "-o follow_symlinks", which will happily create symlinks, then claim it couldn't create them, then show them as awesome recursive unremovable directories. This broken option may automatically be turned on by a bug in Macfusion (https://code.google.com/p/macfusion/issues/detail?id=284). So if anything, you should "lose faith" in sshfs and Macfusion, not Mercurial.
This will be worked around in Mercurial 2.7. In the meantime, you should be able to run sshfs manually without the option.
(For faster bug fixes, please report bugs to the Mercurial/sshfs/macfusion projects, not random internet question forums.)
I'm running a mixed environment, and keep a central, bare repository where I pull and push most of my stuff. This centralized repository runs on Linux, and I check out to Windows XP/7, Mac and Linux. In all repositories I put the following line in my .git/config:
[core]
autocrlf = true
I don't have the flag safecrlf=true anywhere. First time when I modify stuff on my one Windows machine (XP) there is no problem and when I look at the diff, it looks fine. But when I do the same on the other Windows machine (7), all lines are shown as changed but local line endings are \r\n as expected (when checked in a hex editor). The same applies to a MacOSX can. Sometimes I get the feeling that the different systems wrestle on line endings, but I can't be sure (I'm loosing track of all the times I change specific files).
I didn't use to have the autocrlf set, but set the flag many months back. Could that be causing my current problems? Do I need to clone everything again to loose some old baggage? Or are there other things that needs configuring too? I tried git checkout -- . about a million times, but with no success.
You need to set autocrlf to true on each machine you are working on (in global), or for each copy of the repository (in local). The settings of the repo you cloned from are not applied to your local repo.
The other answer is that you have a mixture of line endings in the files in your repo.
A filter on checkout could be setup for each of the source file type to correct their line endings, and on checkin to reset them to the repo standard.