Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add language code mapping #7

Open
phlax opened this issue Oct 12, 2015 · 12 comments
Open

Add language code mapping #7

phlax opened this issue Oct 12, 2015 · 12 comments
Milestone

Comments

@phlax
Copy link
Member

phlax commented Oct 12, 2015

No description provided.

@dwaynebailey
Copy link
Member

An interesting concept would be to name certain mappings. So e.g. gnu will contain the general mappings for GNU software i.e. ca@venetian, zh_CN, zh_TW and map those to correct codes in Pootle by default.

@phlax phlax modified the milestone: 0.1 release Oct 14, 2015
@phlax
Copy link
Member Author

phlax commented Oct 14, 2015

definitely possible - can you give me some preset lists

phlax added a commit that referenced this issue Oct 15, 2015
@dwaynebailey
Copy link
Member

Just flagging that we want to follow BCP47, for which this validator is really useful.

@dwaynebailey
Copy link
Member

This Python language code library could be useful.

@dwaynebailey
Copy link
Member

Created a langcode spreadsheet to create known mappings, only GNU for now.

@phlax
Copy link
Member Author

phlax commented Oct 18, 2015

@dwaynebailey this now basically works

I havent written tests yet for the presets - but will when i get them. I will probably tidy up the tests a bit at that point. I might also need to add some test for the finder class.

phlax added a commit that referenced this issue Oct 18, 2015
- Added tests
- Added mapper to reverse path lookup
- Fixed the mapping algo

Touch #7
@dwaynebailey
Copy link
Member

@phlax nice. Would be good to have a simple way to track the mappings outside of the code otherwise we have to update them in code which is OK I guess but isn't easy to maintain and adjust.

@phlax
Copy link
Member Author

phlax commented Oct 19, 2015

@dwaynebailey usually i would be against having them in code - but in this case they really do want to be constants. Ie if a user creates their mapping based on a preset - we cant change the preset without breaking their store/file associations

@dwaynebailey
Copy link
Member

@phlax just fearful of a state where we have to make a release everytime we change the mappings. But yes I agree we pretty much need to keep these static. But lets be realistic, if we get these wring we should be able to migrate them even if a user makes use of them. We just need to make sure we catch those and give the users the tools to migrate things.

@phlax
Copy link
Member Author

phlax commented Oct 19, 2015

k - just trying to explain why i havent already proposed that we put these in the db - maybe we should - but that is the reason.

@phlax
Copy link
Member Author

phlax commented Oct 19, 2015

tho - thinking about it - if we are going to put a set of comprehensive/standard langs/codes in the db - then maybe that is the best place for the data.

@dwaynebailey
Copy link
Member

@phlax think you keep missing that mappings I made in the doc pointed to by #7 (comment)

Our previous approach has been to put such shareable data into ttk. But I'm not worried about that now. Just flagging the lets load data into DB thinking as there are other places where we likely want to use these mappings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants