It's just an information for your consideration. When I checked tests for Russian language, I noticed, that month names are in one particular form (case). It's, probably, OK for date formatting, but may be not enough for general use. To better understand what I mean, try to open and compare links at this page: http://www.localeplanet.com/compare/ru-RU/index.html.

Basically, there are different forms (cases) of nouns in Russian language, with different endings, depending on usage context. Something similar to English verb forms. While in English you can use "January" as a title in the calendar and to format dates (21st of January; January, 21), in Russian you will need different noun forms for it. You should use "Январь" as a title in calendar, but "21 января" in formatted date. Sometimes I encountered format like "Январь, 21" but it usually feels cumbersome.

Notice, that in your project, you used translations from CLDR (ICU based on it as well), which is more suitable to format dates, but does not contain translations to be used as titles in calendar. Interestingly, Java decided to use nominative case, more suitable for titles in calendar, than for formatting.

Which way is better, depends on the intended library usage. For formatting only current variant is OK. For general use, it preferable to have both variants. Probably, it could be solved with a way to provide custom translations. Setter or builder, or configuration file with custom translations and formats - don't know.

BTW, in Java you not only have a way to programmatically customize formats, you also can supply property files in your package. You even can put this files within your archive at the path were system default files used to be. Due Java class loading mechanics, this custom files will overwrite system ones, so you can replace default translations with your custom property files if put them in right place.

The en_GB locale has incorrect date formatting. The UK uses the DD/MM/YYYY format as per most of Europe, not the US style MM/DD/YYYY format.

I had a very quick look at the unicode CLDR but didn't see exactly where this was specified for individual dialects. I would be surprised if this was wrong as a US date format often causes complaints from users. I did find other auto generated data has the correct format, e.g. https://github.com/unicode-cldr/cldr-dates-full/blob/master/main/en-GB/ca-gregorian.json

Hence I was wondering if this was a code generation issue?

Is there a way to load locales based on a runtime variable?

I'd rather not import every package prior to knowing the locale. :)

go get github.com/go-playground/locales: github.com/go-playground/[email protected]: unexpected EOF

Description

This issue follows from #41 where the same bug is present in a number of the 'en' locales. Any of the en locales which should be formatting time according to the h hour pattern will cause the same bug.

To Reproduce

package main

import (
	"fmt"
	"time"
         en "github.com/go-playground/locales/en_AE"
)

func main() {
	datetime := time.Date(2016, 02, 03, 0, 0, 1, 0, time.Local)
	l := en.New()
	fmt.Println(l.FmtTimeShort(datetime))
}

That code should print 12:00 am but instead it prints 0:00 am.

Changes Required

#44 addresses this fix for the en locale. The same fix needs to be applied to the set of en locales below:

• en-001
• en-AE
• en-AG
• en-AS
• en-AU
• en-BB
• en-BM
• en-BS
• en-CA
• en-CY
• en-DM
• en-ER
• en-FJ
• en-FM
• en-GD
• en-GH
• en-GM
• en-GU
• en-GY
• en-HK
• en-IN
• en-JM
• en-KI
• en-KN
• en-KY
• en-LC
• en-LR
• en-LS
• en-MH
• en-MO
• en-MP
• en-MW
• en-MY
• en-NA
• en-NZ
• en-PG
• en-PH
• en-PK
• en-PR
• en-PW
• en-SB
• en-SD
• en-SG
• en-SL
• en-SS
• en-SZ
• en-TC
• en-TO
• en-TT
• en-UM
• en-VC
• en-VG
• en-VI
• en-VU
• en-WS
• en-ZM

The vulnerable version has been updated in master but there has not been an official release since (0.13.0).
May we have a new release to include pull #31?

Noticed while looking into a dependent package: go-playground/validator#773

Hello,

While using the en_US Translator, I noticed that all the currency symbols are just the short-names USD, INR, EUR, etc, but there are no symbols ($, ₹, €). Is there a way to specify my own currency symbols while initializing a Translator?

I use formatter for output to the form and I want to parse formatted value from form too.

I can`t get decimal, group and minus for creation float number. I wanna replace:
decimal -> "."
group -> "" (delete)
minus -> "-"
and after parse to number.

Could you add getter methods to generated files?

Please remove or rename the tq�q file. It prevents cloning this repository with Windows.

es-mx's group shouldn't be .: link
From CLDR's JSON data: link

es's group is '.'.

I think the parentLocales aren't being followed correctly. But I will explore soon to learn more.

This library depends on golang.org/x/text v0.3.6 having a valnerability GO-2022-1059.
ref. https://pkg.go.dev/vuln/GO-2022-1059

It should be updated v3.0.8 or higher.

Release 0.12.0 does not pass unit tests with Go 1.10. At least:

+ GOPATH=/builddir/build/BUILD/locales-0.12.0/_build:/usr/share/gocode
+ go test -buildmode pie -compiler gc -ldflags '-extldflags '\''-Wl,-z,relro  '\'''
# github.com/go-playground/locales/ru
./ru_test.go:932: Errorf call has arguments but no format

package main

import (
	"fmt"
	"time"
	"github.com/go-playground/locales/en"
)

func main() {
	datetime := time.Date(2016, 02, 03, 0, 0, 1, 0, time.Local)
	l := en.New()
	fmt.Println(l.FmtTimeShort(datetime))
}

That code should print 12:00 am but instead it prints 0:00 am.

12 hour time does not have 0 hours.

definition

import (
    "github.com/go-playground/locales/zh_Hans_CN"
    "github.com/go-playground/validator/v10/translations/zh"
)

// ...

rans, _ = ut.New(zh_Hans_CN.New()).GetTranslator("zh")

type Test struct {
    Urls     []string `json:"urls" validate:"unique" label:"urls"`
}

output

Key: 'Test.urls' Error:Field validation for 'urls' failed on the 'unique' tag

go get: github.com/go-playground/[email protected]: unexpected EOF

The current data is 6 CLDR releases behind, so let's track the update here.

Timezone abbrivations are (sadly) not unique, e.g. IST is (Israel/India/Irish) Standard Time.
(https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations)

Related issue elsewhere: osTicket/osTicket#3583

Lookup for full time is done by abbreviated name, so this happens:

loc, _ := time.LoadLocation("Asia/Jerusalem")
datetime := time.Date(2016, 02, 03, 9, 0, 1, 0, loc)
l := en_US.New()
fmt.Println(l.FmtTimeFull(datetime)) // 9:00:01 am India Standard Time

Hi @deankarn

It is been a while since you updated this repo to CLDR version 32.0.1, currently, the latest stable version is 36.0.0 which released last Oct. If you are not available, I'd like to help the work if you could share the steps on updating the CLDR for go-playground/locales

many thanks,

Help with tests requested,

there are so many locales I just don't have time to add tests for all of them. The locales were generated from the CLDR Project, of which some information may not be 100% correct and the only way we're going to find that out is with tests 😄

you can use this test of the 'en' locale as a frame of reference for tests

Thank you in advance!

What abbout support for Durations?

I would need something like FmtDuration(d time.Duration) to get "20 days 10 hours 5 minutes 3 seconds"

I started write test for russian and found this bug with FmtNumber. Run test and get:
Expected '1 123 456,56' Got '1 123 456,56'

And I found this:
bytes: '%!(EXTRA []uint8=[49 194 160 49 50 51 194 160 52 53 54 44 53 54], string='; ', []uint8=[49 32 49 50 51 32 52 53 54 44 53 54])

Sign "group" in Russian is 194 160 is NO-BREAK SPACE and it`s not equals with 32 SPACE. If someone will write test then he will get error in tests.

First, let me thank you for this beautiful package.

I think there is missing check for the length of decimal, group and minus fields used for number formatting, as I'm getting runtime error: index out of range with locales/cs.(*cs).FmtCurrency

If these are not available in the cldr data, locales package should not panic.

But if I look into the cldr, i see them there (for cs.xml), so there probably some problem with parsing them? Have you opensourced the parser/generator?

In the Readme, it's mentioned that:

fmt.Println(l.OrdinalPluralRule(21, 0)) // 21st
fmt.Println(l.OrdinalPluralRule(22, 0)) // 22nd
fmt.Println(l.OrdinalPluralRule(33, 0)) // 33rd
fmt.Println(l.OrdinalPluralRule(34, 0)) // 34th

But the actual output is:

One
Two
Few
Other

Nice work, however when dealing with unknown locales, say based on the browser settings of users in a Web application, it would make sense to dynamically load locale data from a Json files right?

go get github.com/go-playground/locales

can't load package: package github.com/go-playground/locales: no Go files in /home/$USER/go/src/github.com/go-playground/locales