Please fix GlotPress export. file names

[Gabriel Reguly]

Files are exported like pt-br.mo, but WordPress? expects them as pt_BR.mo.

That is confusing to users getting them from GlotPress to fix their broken themes.

This looks more like a matter of taste not really a bug/issue. Also changing the way files are exported might break APIs using it already. So unless there's no real usecase with this, I'm marking it as invalid, feel free to continue the discussion though.

It is a question of standardization of the po, not personal taste. The correct nomenclature for files in Brazilian portuguese is pt_BR, Portuguese of Portugal is pt_PT. the same happens with other languages.

In GNU.org:

Language
Fill in the language code of the language. This can be in one of three forms:
‘ll’, an ISO 639 two-letter language code (lowercase). See Language Codes for the list of codes.
‘ll_CC’, where ‘ll’ is an ISO 639 two-letter language code (lowercase) and ‘CC’ is an ISO 3166 two-letter country code (uppercase). The country code specification is not redundant: Some languages have dialects in different countries. For example, ‘de_AT’ is used for Austria, and ‘pt_BR’ for Brazil. The country code serves to distinguish the dialects. See Language Codes and Country Codes for the lists of codes.
‘ll_CC@variant’, where ‘ll’ is an ISO 639 two-letter language code (lowercase), ‘CC’ is an ISO 3166 two-letter country code (uppercase), and ‘variant’ is a variant designator. The variant designator (lowercase) can be a script designator, such as ‘latin’ or ‘cyrillic’.
The naming convention ‘ll_CC’ is also the way locales are named on systems based on GNU libc. But there are three important differences:

In this PO file field, but not in locale names, ‘ll_CC’ combinations denoting a language's main dialect are abbreviated as ‘ll’. For example, ‘de’ is equivalent to ‘de_DE’ (German as spoken in Germany), and ‘pt’ to ‘pt_PT’ (Portuguese as spoken in Portugal) in this context.
In this PO file field, suffixes like ‘.encoding’ are not used.
In this PO file field, variant designators that are not relevant to message translation, such as ‘@euro’, are not used.
So, if your locale name is ‘de_DE.UTF-8’, the language specification in PO files is just ‘de’.

I agree with the underscore instead of dash question, after all it's what WordPress? itself expects, that said,

In GNU.org:

This is irrelevant, what counts is what's in locales.php, and which should be used, specifically (locale)->wp_locale (from the looks of it, it seems that (locale)->slug is being used for export file names).

I don't think this will break API's that using this. Most API's download the file and rename it. So we should look how we can make the export work better. I guess we should provide a setting to provide how the file should be named. This because the WordPress? projects doesn't need the project name before it. And I have no clue how it works for the mobile translations.

Good point. Makes me think that maybe we could have an "Export File Name" setting for each project. (i.e. in /projects/<proj>/-edit)

Should we close this in favor of #198?

Anilto can you please stop responding the same issue in multiple tickets. The issue is the same and it is best to have the discussing in one place.

I'd actually rather we close #198, and leave this one open (for now), as there's more context here. Agree?

Agreed and closed #198

I apologize for I had been responding in several tickets. My English is very poor and I not was imagining wich I was being redundant.
As for the naming, I think, as it is a translation tool, she should observe a standardization in the generation of files ( the best way is to follow the recommendations of the GNU.org and Standard ISO 3166 and ISO 639) and/or allow a user inform this name, as already suggested.

Thank you, and I apologize again.

There isn't really a standard if I look at the mobile export types. Not sure about that and will ask for feedback. This will make sense for when there is the ability to download all translations of a project. See #154

For Dutch:
iPhone: /nl.lproj/Localizable.strings
Android: /values-nl/strings.xml
Windows Phone /LocalizedResources?.nl.resx

Again,

should observe a standardization in the generation of files ( the best way is to follow the recommendations of the GNU.org and Standard ISO 3166 and ISO 639)

No, not really. The translation files should be named as the end software expects them, not any other way. I.e. the WordPress? export file for Portuguese should probably named pt_PT for core, admin-pt_PT for the dashboard and so on. The pt_PT part is what GP already has under the appropriate variable in locales.php.

Added:

We already have wp_locale, nothing against having ios_locale, android_locale, and so on.

First try for PO/MO Files

I added the first patch what lets you define the name in the format. Reason is that is can be different for every format.

This patch fixes the name for PO/MO files when there is a WordPress? locale defined otherwise fallback to current naming.
There are a few locales that don't have a locale defined

In 752:

Change filename for po/mo files. Other formats can be looked into later. Fixes #206

This broke a lot of scripts on WP.org, so I need to revert it for now. I'm also not sure this is actually a good idea.

If we are going to use wp_locale here, we should really adopt it *everywhere* and ditch these GlotPress-only language codes entirely. Otherwise, could this be a plugin (which I am happy to run on WP.org)? What's the point of the GP-specific language codes otherwise?

In 766:

Revert [752] pending further consideration. see #206.