Change primary folder structure for reliable sorting and better culture-specific labels #18
Comments
iJungleboy
changed the title
|
Make sense, but for packages we agreed with @sbwalker to use |
|
@hishamco I don't see a problem with having the packages having a longer, more explicit name. What would the |
|
|
|
@hishamco that's perfect IMHO. |
|
I posted a lot of thoughts about the current state of Localization in this issue:
|
|
@sbwalker Based on this my understanding is that there are a few more challenges, but my question for the main folder-names hasn't been answered. But to combine this, I believe the best folder structure would be
Just as an input: I believe Peter Donker created a system to manage resources across versions for DNN. Something like a Database to manage stuff and compare versions. It was blogged about https://www.dnnsoftware.com/community-blog/cid/144731/introducing-dnn-translator-a-new-translation-tool-for-dotnetnuke and is currently on github here: https://github.com/DNN-Connect/DNN-Translator Donno if this helps. |
|
@hishamco @iJungleboy now that 2.1 is out we need to reorganize this repo so that the language resources are organized by version... and we should create individual nupkg packages for each languge so they are installable. |
|
@iJungleboy I took a look at the code for Peter Donker's tool and it appears that it would take a lot of effort to make it work for Oqtane. Have you ever looked at ResXManager: https://marketplace.visualstudio.com/items?itemName=TomEnglert.ResXManager - it is a popular open source project which is a member of the .NET Foundation. It does a nice job of comparing RESX files in folders and identifying missing keys. It has a snapshot feature as well so you can compare to a previous version.
|
|
@iJungleboy Most tools operate based on folder hierarchy so the repo organization should be structured in a way which optimizes the main localization management use cases. The main use case I can imagine is within a specific Oqtane version you want to compare the RESX files for various languages ( usually comparing a custom language to the neutral language ). This allows the translator to ensure that their language resources contain all of the resource keys for that version. In order to accomplish this it would seem to make more sense to organize files by version first and then language:
This also makes it very easy to identify which languages have been translated for a specific version, and which have not. Obviously for each new Oqtane release, a new version folder would need to be created and a subfolder would need to be created for the neutral language resource files. These resource files would need to contain the full set of resource keys for that specific release - and if we adopt the immutable(static) key approach discussed on #17 then the neutral resources would need to be naturally maintained as part of the standard development effort ( eliminating the need for any tool to extract resources from the code itself ). And if a translator then wanted to create the language resources for a new version they could copy the folder from their previous version as a starting point and then run a tool like ResXManager which allows them to visualize which keys are missing by comparing their new folder to the neutral language folder for that same version. I am interested in hearing your thoughts... |
|
IMHO the repo should have the latest translation, leave NuGet package keep track the versioning (no need to reivent the wheel) |
|
@hishamco I am not following your comment. Are you saying that whenever a new Oqtane version is released ( or 1 week after ) Nuget packages should be generated for each language managed in this repo? And these nuget packages would be stamped with the framework version number? I would imagine that some language resources will be maintained regularly by translators and others will not - which means the quality of the version based nuget packages will be very inconsistent. |
|
We need a real world work flow which will facilitate ongoing language resource maintenance and package creation. I am open to suggestions... |
You are right, so the generated NuGet packges should be based on some critieria one of them the maintainability. If there's no activity from previous release to upcoming one no need to publish a translation NuGet package, this way the maintained one will be published regularly |
1 similar comment
This comment has been minimized.
This comment has been minimized.
|
So if I look at the current repo I see folders with a number of languages - but I have no idea which Oqtane version the resources were created for... so I can't create installable nuget packages and I have no idea if the resources I clone will work with my version of Oqtane. At the very least I need to be able to easily determine which Oqtane version that resources relate to. |
|
Regarding the package creation it could be automated via PowerShell scripts, I already did similar thing, but we could do that manually for the upcoming release. Let me know if I can handle or assist in this step For versioning we could utilize the tagging feature in GitHub too to archive the translation versions, but I'm still see publishing a NuGet packages will be valuable for active translations |
You are totally right, but I think this will introduce an overhead to maintain all the versions. Tagged version may usefual in this case, but we enchourage people to you use the latest and greates |
|
Each language in this repo will be in a different state of maintenance in regards to being updated to the latest version at any given point in time. So you are saying that once a translator has updated their language resources for a specific Oqtane version they would need to remember to tag only their own folder with the appropriate version number. And other people interested in utilizing those resources would need to examine the tags on specific folders to determine the version. That does not sound like a good solution... and it is not even technically possible with Git. |
|
The requirements I am looking to satisfy are: Whether you are a developer, translator, or user... and whether you are using raw language resources or nuget packages containing satellite assemblies... you need to easily be able to quickly and easily identify the resources for a specific language that matches your installed version of Oqtane. This repo should be organized in a way that satisfies this requirement. And like I said I am open to suggestions. The only thing that is clear to me right now is that the current workflow for resource management is not functional. |
|
According what you said we need sort of resource extractor that's adapte in every release, then the maintainer needs to fill in the missing translation as fast as possible before the next version is release. This is may make things complicated IMHO the repor should focus on the latest translations (Last release)
Look for the NuGet package that match your version At the end NuGet can simplify the versioning for such scenario |
|
You make a good point... in all other cases a repo represents the latest version of assets ( unless you are using multiple branches ). So this repo should contain the latest versions of resources for various languages. And to satisfy the requirement of being able to determine the current "state" of the resources for a specific language ( ie. the Oqtane version they related to ) I think we should follow the example already set by @iJungleboy with his README file in the German folders. Its very easy to look at the README and see information about the resources for a language. I also went ahead this morning and created a functional nuspec and package.cmd which I placed in the de-DE folder as an example ( these files should be created in each language folder ). The idea is that when someone copies the language folder to the Oqtane.Client/Resources folder it contains the assets needed to package the satellite assembly into a nuget package with the proper naming, etc... So basically they copy the folder, build Oqtane, and then run the package.cmd and it creates the nupkg. |
|
The process for a translator to determine the missing keys will become much easier once we transition to using static keys and we ensure that a complete set of the neutral (EN) resources are constantly being maintained for the current framework. |
|
For anybody following this thread, the last comment of @sbwalker refers to #17 to use keys for resources instead of the original English text. @sbwalker I believe publishing nuget packages for each language would help sites a lot - because most will just want to install or update the language pack and forget about it a moment later. I see some challenges there, but I thought it's better to create a separate issue for this aspect #25 |
|
No further action |
The current folder structure will not scale well when a lot of languages are added, because sorting will make it hard to spot the right languages. I recommend the primary identifier comes first - being the language code itself with an addition. Optionally with the localized term in brackets.
So I recommend:
de-CH German-Switzerland (Deutsch-Schweiz)de-DE German-Germany (Deutsch-Deutschland)nl-NL Dutsch-Netherlands (Nederlands-Nederland)This ensures that it's always consistent from A-Z sorting and it's clear if a language pack has been added. It also ensures that similar language packs are side-by-side as they will start with the same language code.
The text was updated successfully, but these errors were encountered: