The auto id field, may not be a problem, i removed it for convenience for a
couple of reason:
- iterate form.fields in the view to create the html. in this case was not
needed but also the special treatment as it should lie on hidden inputs.
- the type checking on this case was validating the id which was not part
of the factory declaration, not accepting the form. Ofc this could be
solved with some code refinement and leave everything how it is.
> We really don't want to try to replicate validation logic directly in the
> form methods -- you would not only need to validate the data but also
> provide a way to specify error messages as with the validators. It would be
> a big unnecessary mess.
>
Hmm i dont know if you would like this but i have also thought about it.
Validator's error messages could be done by web2py translator, kinda like
IS_DATE already does for date formats. If these messages are automated they
could be easily changed at the translation file instead of having to
declare them everytime on all the apps. Would also shorten the Fields
declarations this way.
I have been recently involved in a project to translate a custom complex
app and been thinking on ways to improve web2py translator.
Improvable things im planning to change on my project would be.
- Load the translations within a module to stay in memory when the server
starts. Not sure if this is already happening or are being read from disk
on demnand.
- Plurals should not be translated by themselves without their contexts as
they may change the grammatical form of sentences depending on the language.
There is a mechanism that i like which is to store pluralizable sentences
as dictionaries, for example:
"15 items found."
the translation declaration could be:
{"%(count) items found": {
"zero": "No items found"
, "one": "one item found"
, "many": "some items found"
, "other": "%(count)s items found"
}
}
then T("%(count) items found", count=1)
will detect this is a pluralizable string since the translation is a
dictionary expecting the count parameter.
Then will choose the right pluralized translation.
The "many" keyword could be also configurable.
There would be no need to have 2 separate translation files (not a problem
if they are), neither isolate plural words from phrases to be translated.
Also take care of plurals genetive saxon "The children's ballons" and other
syntaxis or grammars on other languages.
Translators would have context to translate the sentences.
It goes without saying this would break compatibility but it would make my
app much more easy to handle.
Please let me know any thoughts.
Best Regards.
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
