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

Fixing i18n #7

Merged
merged 32 commits into from
Jul 13, 2015
Merged

Fixing i18n #7

merged 32 commits into from
Jul 13, 2015

Conversation

brenes
Copy link
Member

@brenes brenes commented Jul 13, 2015

i18n was not right when you tried to load content in more than one language.

We just needed a way to tell which contents should be internationalized and which ones shouldn't.

brenes added 30 commits July 6, 2015 16:19
We intend to reuse it (as much as we can) in the Translation class, but
first we are checking that no test breaks in the process
We also limit the line length to 80 characters
We need to be able to ensure that our tests are covering the whole code
(although it may not mean all the cases) and debug when a test get broken
Globalize doesn't manage translations until the block is validated. We must have
all the behaviour regarding translations in the model, not in the translation
We must not look for the layout in the serialized fields
We had problems with the default translation being wiped out because
the fields_info attribute was set to blank for some reason
We don't always want all the fields to be translated, so
we need a place to store those fields
Since we're starting to do some operations with the layout configurations
we move it to a class that can perform every operation
We prepare the layout for the case where a field has to receive a
more complex configuration than just the type
Now that there will be not translated fields we need the layout to
be only one and shared by all the other locales
I know I shouldn't modify a migration but since it's not even pushed
it seemed fine.

We are trying to use the same names and do it in a transparent way.
Since we moved the layout to the block we need to be able to pass
the layout to the translations when they are being created.

Otherwise we wouldn't know if a field belongs to a translation, because
we still don't have the reference to the globalized block
By default the block will be translated (it will be the expected
regular behaviour), and our layout configuration allows us to obtain
the translated and not translated fields
We load the fields configuration depending if we are on a block or on
a translation.
…ranslation

We also have our first green test about fields translated and not translated
It makes sense that if you ask a block about a field it has (although in
a translation) it returns true. We will have to manage the division between
the block and the translation both in the method missing and in the
attributes assignment
Now translation may have its own related objects, and we should store
and save them in an independent way
…s changed

Otherwise translation would not be saved and changes to an associated object
would not be saved
We are adding now a default configuration and the test must take it into account
brenes added a commit that referenced this pull request Jul 13, 2015
@brenes brenes merged commit 1fb8fd3 into master Jul 13, 2015
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

Successfully merging this pull request may close these issues.

None yet

1 participant