Custom Query (2152 matches)
Results (787 - 789 of 2152)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#1492 | wontfix | Interference between extra and relationship fields in API | kindly | dread |
Description |
From Jan Kučera <elquenor@…>
|
|||
#1491 | fixed | Visible strings need internationalisation | seanh | dread |
Description |
Sean spotted that some strings need internationalising, such as flash messages. Generally all strings that appear on the web front-end should be internationalised. Particular places that need i18n:
Note: there are some exceptions, such as in i18n.py, very obscure error messages and stuff that only appears on the API. NB: there is a cost in making a string internationalisable (all our volunteers have to translate it), so we should not be too zealous. We should also look at the i18n/ckan.pot to see if any of the existing strings can be reused. |
|||
#1490 | fixed | Standardize output from package listings coming from the logic layer | amercader | amercader |
Description |
Right now, the two logic functions that return a list of packages (package_search [1] and group_packages_list [2])use custom functions to generate the output dict. That's suboptimal because:
In general only the functions present in lib/dictization/model_dictize.py should be used to build the output of a logic function, in that case package_dictize. If necessary, they can be modified to include missing properties, like on this particular case the "isopen" property, needed by the template renderer. [1] https://github.com/okfn/ckan/blob/master/ckan/logic/action/get.py#L685 [2] https://github.com/okfn/ckan/blob/master/ckan/logic/action/get.py#L442 |