On Fri, Mar 13, 2020 at 5:48 AM Jon Perryman wrote:
> This comment is from the proposal. Not one person has disagreed with "very
> powerful". If you disagree, please say why? How is this not far more
> powerful than GO GENERATE, pre-processors and macro's?
>
No one is disagreeing with that, beca
On Wed, Mar 11, 2020 at 12:23 AM Levieux Michel wrote
> It seems you missed something here. "Please like my proposal or everyone
loses" is not an argument.
No one has debated the power, importance and virtues of my proposal.
Apparently you didn't read the comments in the proposal. The discussion
Ah, OK.
On Wed, 2020-03-11 at 01:58 -0700, miha.vrhov...@gmail.com wrote:
> https://github.com/golang/text/pull/9
>
> And I cannot find the issue, but there are a few with extract command
> not working and crashing.
>
> On Wednesday, March 11, 2020 at 9:40:36 AM UTC+1, kortschak wrote:
> > Why d
https://github.com/golang/text/pull/9
And I cannot find the issue, but there are a few with extract command not
working and crashing.
On Wednesday, March 11, 2020 at 9:40:36 AM UTC+1, kortschak wrote:
>
> Why do you say that?
>
> ~/src/golang.org/x/text/message [master*]$ go env GO111MODULE
>
Why do you say that?
~/src/golang.org/x/text/message [master*]$ go env GO111MODULE
on
~/src/golang.org/x/text/message [master*]$ go version
go version go1.14 linux/amd64
~/src/golang.org/x/text/message [master*]$ go test
PASS
ok golang.org/x/text/message 0.024s
On Wed, 2020-03-11 at
AFAIK this doesn't work in recent go versions and even less if you are
using modules.
On Wednesday, March 11, 2020 at 6:39:36 AM UTC+1, Tamás Gulácsi wrote:
>
> Hi Jon,
>
> Have you read https://godoc.org/golang.org/x/text/message ?
>
> It's not gettext, but a better - though not perfect - soluti
Hi Jon,
It seems you missed something here. "Please like my proposal or everyone
loses" is not an argument. We don't work that way here. You have suggested
the language needs a feature, and have gotten many answers from people that
think it does not.
Keeping on repeating the same argument forever
Hi Jon,
Have you read https://godoc.org/golang.org/x/text/message ?
It's not gettext, but a better - though not perfect - solution for this i18n
problem.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop r
Is there anyone who dislike's this proposal able to describe an acceptable
implementation of gettext in GO? The concept is simple. Convert a message
into another language including date, numbers, day of week, and plurals.
The current gettext:
1. is a CPU hog and intolerable for a large number of m
Everyone needs to like proposal
https://github.com/golang/go/issues/37292.The following response proves the
importance of a compile time language.
> In C it's called _.
> Then: "fmt.Println(G("message text at %t with %n bytes"), time, number)
> Notice that (following C) the gettext lookup functio
Hi Jon,
first, I want to be open and say that I agree with what has been said by
others in the issue discussion. I don't think this is a good idea, for all
the reasons Ian and Robert gave.
On Tue, Mar 10, 2020 at 6:31 PM Jon Perryman wrote:
> There are many examples where compile time flexibili
In C it's called _.
While it's not normally considered good Go style, you could use a "."
import of the package, and call the function G.
Then: "fmt.Println(G("message text at %t with %n bytes"), time, number)
Notice that (following C) the gettext lookup function is called with the
string, and n
If proposal https://github.com/golang/go/issues/37292 fails, everyone will
lose out on a great opportunity. API's can be greatly simplified. Writing
pre-processors and GO generate don't completely meet our truly meeting our
needs. Is the extra implementation work worth the effort? Do we live wit
13 matches
Mail list logo
