i18n-pt_BR: synchronized with a0e46f6b248b

zsh_completion: install as _hg not hg The contrib/zsh_completion file itself says to name it _hg. With a name like `hg`, if the user has a line like `autoload ${^fpath}/*(N-.:t)` in their zshrc, it will create a shell function named `hg` that will hide the actual hg command and make hg unusable. Separately from that though, the underscore prefix makes it actually work. The zsh man page states: The convention for autoloaded functions used in completion is that they start with an underscore This does not seem to just be a "convention", though. With the ill-advised line removed from my zshrc and the file named `/usr/local/share/zsh/site-functions/hg` (without the underscore), these completions did not seem to get loaded and the ones from the zsh installation were loaded instead. If I renamed them to be `/usr/local/share/zsh/site-functions/_hg`, however, they were loaded. I manually tested the above statement by starting a new zsh instance with the file in `/usr/local/share/zsh/site-functions` with the following names: - As `hg`, `which _hg_labels` did not show anything - As `_hg`, `which _hg_labels` showed the expected function.

osx: override default exclude filter for pkgbuild To quote `man 1 pkgbuild`: --filter filter-expression By default, --root will include the entire contents of the given root-path in the package payload, except for any .svn or CVS directories, and any .DS_Store files. You can override these default filters by specifying one or more --filter options. Each filter-expression is an re_format(7) ``extended'' expression: any path in the root which matches any of the given expressions will be excluded from the pack- age payload. (Note that specifying even one --filter inhibits the default filters, so you must respecify the default fil- ters if you still want them to be used.) It turns out the default filter these days *also* includes .git and .hg. Notice how that filter expression is a regular expression? That (presumably unintentionally) prevents a file named "chg" or "_hg" from getting included in the distribution. Many many thanks to spectral@ for trying to include a _hg file which led us to figure this bug out. Bug filed with Apple for this as rdar://problem/32437369, mentioning both the gap in documentation and the wrong defaults.

bugzilla: fix typo in help text

help: fix typos

win32mbcs: avoid unintentional failure at colorization Since 176ed32dc159, pycompat.bytestr() wrapped by win32mbcs returns unicode object, if an argument is not byte-str object. And this causes unexpected failure at colorization. pycompat.bytestr() is used to convert from color effect "int" value to byte-str object in color module. Wrapped pycompat.bytestr() returns unicode object for such "int" value, because it isn't byte-str. If this returned unicode object is used to colorize non-ASCII byte-str in cases below, UnicodeDecodeError is raised at an operation between them. - colorization uses "ansi" color mode, or Even though this isn't default on Windows, user might use this color mode for third party pager. - ui.write() is buffered with labeled=True Buffering causes "ansi" color mode internally, regardless of actual color mode. With "win32" color mode, extra escape sequences are omitted at writing data out. For example, with "win32" color mode, "hg status" doesn't fail for non-ASCII filenames, but "hg log" does for non-ASCII text, because the latter implies buffered formatter. There are many "color effect" value lines in color.py, and making them byte-str objects isn't suitable for fixing on stable. In addition to it, pycompat.bytestr will be used to get byte-str object from any types other than int, too. To resolve this issue, this patch does: - replace pycompat.bytestr in checkwinfilename() with newly added hook point util._filenamebytestr, and - make win32mbcs reverse-wrap util._filenamebytestr (this is a replacement of 176ed32dc159) This patch does two things above at same time, because separately applying the former change adds broken revision (from point of view of win32mbcs) to stable branch. "_" prefix is added to "filenamebytestr", because it is win32mbcs specific hook point.

tests: fix typo in "flagprocesor"

contrib: remove unnecessary debug output from editmergeps.ps1

contrib: fix a bug preventing editmergeps.ps1 from running unknonw editors '$ executable' is not a way to run executable in powershell, '& executable' is instead. Found this when testing with regular Windows notepad.

contrib: make editmergeps use -NoNewWindow option in Start-Process cmdlet Running 'Start-Process -Wait "vim" "+10" "filename"' from PowerShell actually spawns a separate cmd window to run vim in. This looks ugly and in most cases not what user wants. During my initial testing I was using the Cmder app, which made me not notice this (it captures new windows as new tabs).