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 function is called with the
string, and not with extra arguments.
> Seems fine to me. Needs no language changes.
One key feature is simplification. This isn't simple when an experienced
gettext( ) and GO developer can't code it correctly.
1. Placing time and number are outside gettext() means they are not
localized. Does fmt.Println( time.Now, 1000.55) display something you want
in a message?
2. Placing time and number in the message text requires it be in a form
gettext can identify. I doubt they are supported so you must find a
compatible format. Time for more documentation.
3. The actual statement is fmt.Println( G( fmt.Sprintf( "message text at %v
with %f bytes", time.format(??), number).
Most people do not understand the importance and capabilities that a
compile time language would bring to GO. For instance, the cpu overhead was
ignored here.
This proposal is not specific to gettext. A compile time language is a must
and should be on GO's radar because many API's would benefit. This is a
feature that will radically improve GO with little effort. You should
"like" this proposal to let them know it's important.
Thanks, Jon.
On Tue, Mar 10, 2020 at 10:38 AM Thomas Bushnell, BSG <tbushn...@google.com>
wrote:
> 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 not with extra arguments.
>
> Seems fine to me. Needs no language changes.
>
> On Tue, Mar 10, 2020 at 1:31 PM Jon Perryman <jon.perry...@gmail.com>
> wrote:
>
>> 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 with mediocre solutions to avoid repetition? Why do we live with
>> mediocre solutions because we don't have compile time logic? Please
>> consider "like" of this proposal otherwise we will miss this great
>> opportunity.
>>
>> 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):
>>
>> - 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 golang-nuts+unsubscr...@googlegroups.com.
>> 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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAByJhJnzBgwbDRG8pohDDU0d6%3DVVwvGq2y2asgzxqX91Ph0sSg%40mail.gmail.com.
