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 <[email protected]> wrote: > There are many examples where compile time flexibility is important. > Consider the adverse effect of GO limitations has had on the very important > GNU GETTEXT( ) - native language support (multi-lingual messages and > localization): > I don't really understand your example. gettext is a C software, written long before Go existed. I don't see how any limitations (perceived or real) of Go could have any effect on it. AIUI you then go into some length of describing a fictional i18n/l10n API and its drawbacks. However, are you aware of https://godoc.org/golang.org/x/text/message, which is a non-fictional such API for Go? It's certainly not perfect, but at least as far as I can tell, it seems to solve the problems you are having in a far more convenient and readable way than what you are suggesting. > > - Documentation is 17 chapters -> > https://www.gnu.org/software/gettext/manual/gettext.html > - Big-o complexity o(n^2)!!! > - It has several important utilities for maintaining translation > catalogs. > - Hundreds of developer's were involved in its design and > Implementation. They came up with the best implementation considering they > don't have a compile time language. > - Use and maintenance is labor intensive and time consuming . > > fmt.Println( gettext( fmt.Sprintf("message text at %v with %v bytes", time > .format( ), number) ) ) > > When to implement Gettext( ) is a difficult decision and lots of work > early in your project. As you can see, gettext( ) is a function call with > the message to be translated. The message must contain everything to be > translated. After determining the language and localization, gettext > searches for a matching message translation rule in the language specific > catalog. The rule is applied to the message and data needing localization > is converted (e.g. dates, numbers, currency). > > fmt.Println( #gettext( "message text at %t with %n bytes", time, number ) > ) > or > fmt.Println( #gettext( msgid="jon001", time, number )) > > Isn't this cleaner and easier to code. Just as important, the big-o > complexity goes to o(n)!!! We could make this even easier by creating a > #gettext.println( ) > > You won't see the #gettext() function unless you are the maintainer of > this functionality. Function #gettext( ) is small and easy to maintain. One > possible implementation for #gettext( ) with this proposal gives you lots > of flexibility and eliminates 90% of the code in the real GNU gettext( ). > > func #gettext( args Args ) { > src := "gettext(" // call real gettext function > current_positional_arg := 1 > if args.msgid != nil { // keyword argument "msgid" not specified > src += args.msgid + " ,nil" > } else { > src += "nil, " + args.positional[1] > current_positional_arg := 2 > } > for ; current_positional_arg <= args.positional.length; > current_positional_arg { > arg = args.positional[current_positional_arg] > if reflect.TypeOf(arg) == "time.Time" { > src += ",gettext.TimeLocal(" + arg + ")" > } else if reflect.TypeOf(arg) == "int" { > src += ",gettext.Number(" + arg + ")" > } else { > src += "," + arg > } > } > compiler.AddStatement(*,src) // replaces the #gettext( ) with real > code > } > > This compiler called function replaces the #gettext( ... ) as follows: > > #gettext(msgid="jon001", number, time) > would be replaced with > gettext("jon001", nil, gettext.Number(number), gettext.TimeLocal(time) ) > > The new gettext( ) is greatly simplified. Messages are now in a easily > accessible GO module. There arel language specific message modules that are > dynamically loaded as needed. E.g. en_jon.go where en is an English message > module and jon is the first part of the message id (e.g. jon001). Gettext( > ) gets the message rule 001 from en_jon.go and applies the rule to the > message. > > It's important that the language specific message modules are simple to > edit by language translators. It also needs to be as similar as possible to > the GNU standard while having GO syntax. > > #msg( language=en, prefix=jon ) // english messages jon### > > // translator-comments > // extracted-comments > // reference… > // flag… > #msg( > id=001, // msg id jon001 > msgstr[0]="message text at %t with %n bytes", > ... > msgstr[N]="message text at %t with %n bytes" > ) > > > // translator-comments > // extracted-comments > // reference… > // flag… > #msg( > id=002, // message id jon002 > msgstr[0]="message text at %t with %n bytes", > ... > msgstr[N]="message text at %t with %n bytes" > ) > > > // translator-comments > // extracted-comments > // reference… > // flag… > #msg( > id=003, // message id jon003 > msgstr[0]="message text at %t with %n bytes", > ... > msgstr[N]="message text at %t with %n bytes" > ) > > Using the #msg( ) function hides the complexity of the real GO code to > make this easy for translators to maintain. > > A compile time language has many more benefits that are not obvious. I > strongly urge everyone to like proposal > https://github.com/golang/go/issues/37292 . > > Thanks, Jon. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/2325901c-906e-4977-a989-5e0c00297052%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/2325901c-906e-4977-a989-5e0c00297052%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfG%2BJBHSiac8_oP9_igY_%2B-gm%2BGmFs9xyK6ppEUccz_qkg%40mail.gmail.com.
