perf: add Portuguese (Brazil) support #1619
Conversation
| } | ||
| if i18nLang != h.i18nLang { | ||
| utils.IgnoreErrWriteString(h.term, utils.WrapperString(lang.T("Switch language successfully"), utils.Green)) | ||
| utils.IgnoreErrWriteString(h.term, utils.CharNewLine) | ||
| } | ||
| userLangGlobalStore.Store(h.user.ID, i18nLang) | ||
| h.i18nLang = i18nLang |
There was a problem hiding this comment.
In summary, we should be checking that:
-
All of your imports at the top work without error on the latest date.
-
The change to
i18nnamespaces is not causing unexpected errors or breaking anything related to other parts of the codebase. -
There are no obvious changes or improvements you can identify from this excerpt. It doesn't seem like there are significant issues with it either.
-
You have made some stylistic improvements to use
switch langinstead ofcase x. This can improve readability depending on how many cases may exist but it's just a minor style point.
Overall, the current code looks fine as implemented based on what you provided. If there are specifics in your feedback then I would need more context about which part or aspect specifically needs to be looked into.
This code was written for an InteractiveHandler class that performs various operations based on input from users such as changing language settings etc. So if these inputs were being used frequently in conjunction with similar code blocks within an application, then further optimizations could include better performance or efficiency checks. For example, if the user selection time exceeds our defined thresholds (likely less than 0.01 second), consider using async I/O methods to speed up response times.
Let me know if you want more advice specific to your requirements!
| "zh-hant": ZHHant, | ||
| "zh_hant": ZHHant, | ||
| } | ||
|
|
||
| type LanguageCode string | ||
|
|
||
| func (l LanguageCode) String() string { |
There was a problem hiding this comment.
No major issues were found, but some changes could be made to enhance readability/clearness and efficiency. Suggestions:
- Move common code like the function
make_mapinto a separate file (if necessary). - Use consistent strings or constants instead of strings concatenated.
- Consider if there's enough information/accuracy needed in such short codes for them not to change frequently.
For example:
// This is slightly more readable than concatenating strings
func LanguageMapping(lang *gotext.Locale) (*LanguageCode, bool) {
if mapping, ok := langMap[lang.Language]; ok { return &mapping.String(), true }
return nil,nil
}Here I use Go's struct equality method with 'ok' check which checks if it already exists in our map. The value returned from this function can also be used without storing extra info (like whether it was just created).
- Optimize variable names:
- Instead of all Lang Codes in one big array, store each unique code as an individual item (you only need these).
The above suggestions don't necessarily involve any significant functional changes; they are aimed at enhancing readability and maintainability.
Keep up the good work! Happy Coding!
| if i18nCode, ok := i18nCodeMap[code]; ok { | ||
| return i18nCode | ||
| } | ||
| return EN | ||
| } | ||
|
|
||
| func T(s string) string { |
There was a problem hiding this comment.
There do not appear to be any irregularities, issues, or areas of optimization related to this Go code snippet from 2021-09-01. The provided functions seem correct, and they perform operations that involve setting up configuration files, configuring languages into locales, loading localized strings, adding domains to locales when necessary, and determining appropriate language codes based on those configurations.
If you have specific questions about the functionality or performance of these methods, please let me know!
|
perf: add Portuguese (Brazil) support