This site uses cookies.
Some of these cookies are essential to the operation of the site,
while others help to improve your experience by providing insights into how the site is being used.
For more information, please see the ProZ.com privacy policy.
This person has a SecurePRO™ card. Because this person is not a ProZ.com Plus subscriber, to view his or her SecurePRO™ card you must be a ProZ.com Business member or Plus subscriber.
Affiliations
This person is not affiliated with any business or Blue Board record at ProZ.com.
Spanish to English: Application Lifecycle Management (ALM) platform General field: Tech/Engineering Detailed field: Computers: Software
Source text - Spanish [N/A, it's an installation and user guide I wrote in English, based on information researched largely in Spanish]
Translation - English Configuration
Open URL
e.g. http://192.168.24.9:3000/
Creating Environments
An environment is a logical grouping of configuration items or resources. These form the basis of [the software]’s configuration. To create environments, go to the left-hand panel and select Resources/All, then scroll down to Bl.
This opens the Bl tab. Click Create to set up a new environment.
The first environment to be created should be named ‘Common’. The Common environment is a special environment in [the software] that holds CIs, resources and variables that are common to every environment or that are not specific to any environment. This is common to all CIs. Unlike other environments, set Baseline ID to *. Click Save. ID and Moniker are assigned automatically.
For all other environments, Name and Baseline ID should be set to the same value as each other, e.g. ‘PRE’.
Follow the same steps for other typically needed environments, such as DEV, PROD and TEST. This list is not exhaustive, and you may need to set up further environments as dependencies for Statuses (see the following section).
Once you have created the necessary environments, they should appear as a list similar to the following example:
Creating Statuses
A status represents the state of an issue at a particular point in a specific workflow. An issue can be in only one status at a given point in time.
To create statuses, go to the left-hand panel and select Resources/All and scroll down to Status.
This opens the Status tab. The first status we are going to create here will be named ‘New’.
From the Environments combo, select Common. The environments created in the previous step are shown here (see Creating Environments).
There are a series of status types; in this example we will assign the Type: Initial.
For other statuses, one of the other status types may be appropriate. In the case of In Dev statuses, the DEV environment should be selected, with Status Type set to Deployable, for instance. Click Save.
Moniker is automatically assigned the value of name on saving, and this will be displayed in uppercase.
Creating Projects
A Project is the most common security scope. A project is a collection of Topics, and is defined according to your organization's requirements.
To create Projects, go to the left-hand panel and select Resources/All and scroll down to Project.
Click Create to set up a new project.
Choose an appropriate name. Add the desired Project Environments (note that Common is the default Environment, and therefore does not appear as a selectable option in the combo). In the Variables combo, select the appropriate variables. Copy Vars To…. shows the available environments.
Save the project for now.
[...]
===============
If you installed [the software] yourself, then you will also have root User login credentials, which are created by default, and grant full permissions in [the software]. In most other cases, you will need to be assigned a User before you can use [the software]. Your Administrator will notify you of your login information:[...]
The password is case-sensitive. You can easily change your password by activating the User dropdown at the top right of the interface and selecting Change password. If external authentication is used, Users must be created in the [the software] Database in order for login to work, however passwords are held centrally on an LDAP server, and Administrators will typically disable your password changing privileges when single sign-on or LDAP/SAML authentication is enabled. You can update your login information at any time, along with session settings etc. We will look at this in User Preferences.
System Users, meanwhile, are identified by means of an API keys, without having to send a password. API keys cannot however be used to log into the [the software] web interface or access any URL, except when the system configuration option api_key_authentication is set to a true value (1) in the YAML file used to specify the MongoD. We will look at API keys in User Preferences.
Display and navigation in [the software] depends heavily on its tabbed document interface (TDI), thereby allowing multiple documents or panels to be contained within a single window, using tabs as navigation for switching between sets of documents.
This makes configuration and looking up information a much more straightforward task, particularly in the latter case, where TBI is combined with the use of items such as Dashboards, Kanban and other types of Boards (which we will look at later on), which can display a large amount of information in one place, such as calendars, tables showing Topics that are in a specific state, project graphs etc. The different Board types selected are opened in separate tabs.
Other features that appear on tabs include dragging and dropping e.g. when creating Resources such as Rules, sub-tabs e.g. when creating Roles, and new windows (often, in turn, containing tabs) etc. when creating Admin items such as Categories, Users and User Groups.
When items are selected from the left-hand menu, a corresponding tab is often opened which often displays a grid containing existing items of that type, as is the case with Jobs, Projects, Statuses, Environments, Topics, Categories, Users etc. The tab also features a Create button, which in turn opens a new configuration tab in most cases, although a new window is opened for Categories, Users etc. The Create menu button on the default Dashboard provides a shortcut to the Create tab or window of a number of the most frequently used items, without having to navigate via the left-hand Menu to the Create button within the various Menu items.
This use of tabs simplifies matters when creating Resources, Admin items, and items more generally. Tabs are particularly useful for toggling during configuration where there is interdependence. They can also be moved by dragging and dropping, so that related configuration tasks are on contiguous tabs, making toggling (and hence, comparing information) more straightforward.
For instance, when creating Categories, there may be configuration details that are not yet available, since we have still not created the necessary Rules, whose configuration may in turn require prior creation of a Category.
Favorites
[The software] allows storage in one place all items considered to be of relevance to the user. The Favorites feature allows all types of tab such as searches, Reports, Topics, Jobs, Resources, Admin items etc. to be stored either as a grid or specific items. Favorites may also be organized by dragging and dropping into in folders, which helps capitalize on space. Each top-level folder may contain a sub-folder. Favorites may be selected by selecting individual saved items from the left-hand menu, or by opening any folders, and selecting the items stored within them. [The software] allows the entering of HTML code into the Favorite name field for enhanced visibility.
User Preferences
The User Preferences panel contains default settings for your account login and session. These can be updated at any time, including changing your session settings and your default workspace or project selection. Your User Preferences settings override any settings that have been applied to the entire workspace.
Settings that may be modified here are as follows:
General
Interface Language - English or Spanish.
Timezone - local time zone, or settings passed from the server or browser timezone all of which may vary.
Country.
Date Format.
Time Format.
Default Dashboard.
==============
Basics
Concepts
Resources
The term Resource refers to the fundamental structural unit of a configuration management system. [The software] is such a configuration management system, keeping track of all its configuration entities as Resources in its database.
In [the software], examples of Resources are Environments, Jobs, Natures, Projects, Reports, Repositories, Scripts, servers, Statuses, Topics (Releases, Changesets, Requirements, Test cases etc.), as well as servers, User IDs, agents, middleware (such as JBoss or Apache), cloud instances, mainframe nodes etc. Each one has its unique Master ID (MID), which [the software] uses.
Any activity involving Resources (create, update and delete) is registered within [the software] in the Stash (see below).
MID
The MID is short for Master ID. This is an internal counter used to uniquely identify Resources in [the software], which is unique per installation or creation, and usually shows up in the [the software] UI prepended by a hash (#) sign.
The Stash
The Stash is a cache containing variables for referencing Job Items, e.g. Changeset identifiers. These will vary from Job to Job, and orchestration is performed via a Release Topic by referencing the MID from one of the Changeset Topics. Stash variables are used to communicate between tasks, and the Stash itself is used to replace the variables in the different configurations.
CI Graphs
This displays a Graph on the Resource in a variety of graph formats in relation to other Resources. The default is Space Tree, which renders the Topic as a linear-type graph, although you may alternate between this and the other formats, which are: RGraph, d3G. RGraph displays the various branches radiating out and intersecting within a series of concentric circles. d3G, meanwhile, shows the different Resources as points, connected by curved arrows.
Admin Items
Admin Items play a central role in how the user interacts with [the software]’s Resources, and how these interact with one another. Of these, Roles are fundamental in that they allow project-specific definition of permissions. These permissions are then assigned to Users or to User Groups, which are also Admin Items. Other Admin Items include: Rules, which are used for customizing most critical aspects of [the software] and play a critical role in Changeset Management, with Rule Management in charge of automation (performed by executing the one or more of a series of Rule types) and deployment among systems; Categories, which pass Rule information information to Topics (which are key to [the software]'s central delivery lifecycle), as well as defining the type of Topic created, whether it be for track changes to assets or orchestration of said process; Daemons, which are a kind of background process; and the Scheduler, which allows you to plan when Jobs (see below) are to be run.
Environments
An Environment can be thought of as a place into which we deploy changes, and is a logical grouping of Resources, with an Environment being itself a Resource. Environments form the basis of [the software]’s configuration.
The Common Environment is a special Environment in [the software] that holds Resources and variables that are common to every Environment or that are not specific to any Environment. This is common to Resources. When creating Statuses (as we will see in the following section), we set the Environment as Common, since the new Topic is not yet in any Environment.
Statuses
A Status represents the state of a Topic (we will look at Topics later on) at a particular point in a specific workflow. Like Environments which we saw earlier, Statuses are also Resources.
A Topic can be in only one Status at a given point in time, and typically there are several Statuses through which a Topic passes during its lifecycle. A Transition is a link between two Statuses that enables a Topic to move from one Status to another.
In order for a Topic to move between two Statuses, a Transition must exist. This workflow is set in Categories (see Categories) or in a workflow Rule.
There are a series of Status types:
Initial - Topic just created and not yet picked up.
Deployable - The developer has finished his or her development, and the Topic is ready for deployment.
Canceled - Topic has been aborted.
Final - Topic has been closed, and should, for instance, not be shown in Topic Grids, Kanbans etc.
Generic - None of the above Statuses are applicable. We could assign the Topic to this Status, for instance, when errors occur, and re-run the Job, or where the Topic is still in development.
Workflows
A workflow in [the software] defines the set of Statuses and Transitions via which a Topic (see Topics) will pass during its lifecycle.
There are two types of workflows:
Topic-based, which are for simple workflows.
Rule-based, for complex or reusable workflows.
Variables
A variable in [the software] is a globally defined Resource belonging to the variable class. Each variable can hold values, like strings, numbers, lists, hashes (dictionaries) and Resources.
Variables can be referenced in Rules using the notation ${variable-name}. When a Rule runs, its Stash is loaded with global variable default values. Then, as the rule advances, either variable values change or new variables are introduced to the Stash.
Different Environments often have the same variables, albeit with different values, and Project configuration can be streamlined by grouping Project Variables in an Environment Template. Moreover, an Environment Template may also contain Variables (and their values) referenced from other Environment Templates. Should the same (or a similar) set of Variables be needed for more than one Environment, these may be copied between Environments, once they have been set in a given Environment. Variables may additionally be selected from Blueprints (see Rules) by first creating a Nature (see Natures) as a container for the Blueprint, which is in turn assigned to a Variable. This can Variable be added to the Environment Template.
Natures
Natures in [the software] refer to technologies (in the form of types of binaries, executables and data) that will here be taken, converted and deployed.
An example of using Natures in [the software] is deployment of files composing a web application e.g. JSP, images, metadata etc. to a web server. These are defined as Natures in [the software], in order for the underlying Rule (see Rules) to detect them. These would then be bundled as a WAR file for use in deployment to the web server.
Natures also play a vital role when selecting Variables from Blueprints (see Variables).
Projects
A Project is one of [the software]’s main security scopes. It is a collection of Topics (see Topics), which is defined according to your organization's requirements.
It may consist of:
A software development project.
A system.
A group of software components.
An application (more commonly).
Topics can belong to zero, one or more Projects. For example, Changeset Topics must belong to one (and only one) Project. Releases, on the other hand, may be multi-project or have no Projects.
Project Variables
Every Project can have a set of Variables with values set specifically for that Project. Moreover, different values can be set for every Environment.
Variables may be configured in an Environment Template according to the Environment(s) in which they are available or are assigned a given value. These Variables are referenced in Projects in a similar way to when referencing simple variables, with the difference that their values are then imported by selecting from the Import Configuration combo the Environment Template in which these were configured.
Categories
Categories are a kind of template for passing Rule and Form information to Topics (see Topics). They define the type of Topic created e.g. Release, Changeset or Generic, and allow other options such as selection of Form Rules and definition of Workflows for the various Roles (see Roles). Here we are chiefly concerned with Changeset and Release Categories. A Changeset Category Topic, each of which has a unique identifier (see MID), holds the revisions from the source code repositories and is the deployable unit in [the software], while a Release Category Topic orchestrates the launch of several Changesets. Generic Category Topics, meanwhile, are non-deployable, and may be used to apply changes within a single Environment.
.
Roles
Roles are a grouping of permissions, which are pre-configurable and assigned on a project-by-project basis. Roles are similar to groups, but differ in that group membership is global, whereas Role membership is Project-specific.This means that, while group membership can only be altered by [the software] administrators, Role membership can be altered by Project administrators.
Roles are used as templates when assigning permissions to Users (see Users) and/or Groups.
Users
Users enable operation of [the software] according to the permissions inherent to the Roles assigned to each User. Note that a root User is already created by default, which allows the creation of other Users (along with the configuration of [the software] generally).
There are two User account types:
Regular for all Users, who can use [the software] with all their functionalities.
System for Users internal to [the software] that cannot log in or surrogate, although they can be used via Rules and API keys. These Users are not counted for the User limit per license.
System users are used in webservices (see Rules), called either from the command line, or from other applications and services. For security reasons, authentication should be required, which in turn requires an API key to be set.
Topics
The Topic is an instance of a Topic Category (see Categories), which in turn is an organization-defined form instance that has an associated workflow, and acts as a template for passing Form Rule information (providing the necessary fields in order to configure the settings for Projects, other Topics etc.) to all Topics, and Pipeline Rule information (for automation), typically used by Changeset Topics via Projects.
Topics are a key entity to [the software]'s central delivery lifecycle, handling both technical components and the different aspects of their delivery process by means of the automatically assigned Master ID (MID). These may include different types of releases, sprints, etc. Topics’ workflows can represent many different logical states and changes attached to these Topics. They also have fields, with role-based security and actions. A Project in [the software] consists of a collection of Topics.
There are a three types of Topic Category:
Changeset Topics
Changeset Topics are used to track changes to assets that are part of the application delivery process. Typically, they may hold the revisions from the source code repositories (e.g. Git branches using drag and drop into Revision Box, the latter being a special form item that allows for dragging and dropping). A Changeset Topic is the deployable units in [the software], and it typically contains (as mentioned) a series of items needed when launching the Job, which we reference via the MID, an internal counter used to uniquely identify Resources in [the software], including Topics, Servers, Users, Projects, Statuses etc. in the the Stash (see below).
Release Topics
A Release Topic is used to group several Topics of other types (either Changeset Topics, Generic Topics or indeed other Release Topics). We can use a Release Topic to orchestrate the launch of a number of Changeset Topics and/or other Topics. This is done by configuring the Form Rule used in Release Category Topics with a Topic Selector fieldlet.
Generic Topics
These are non-deployable Topics, which may be used to apply changes within a single Environment, such as sprints or bugfixes.
Lifecycle
This feature makes it possible to view the Lifecycle of a Topic as a graphical display, which by default shows the entire Lifecycle. Labels may be added to show Roles along with other options for select icons and/or color as visual aids. The Lifecycle may be viewed in Role mode, which displays the various Roles in a series of boxes, which in turn contain the parts of the Lifecycle pertinent to each respective Role.
Rules
Rules are a decision tree used for customizing most critical aspects of [the software]. Once the requisite needs analysis has been carried out, the Rules necessary to achieve the desired objectives need to be defined. Rules play a critical role in Changeset Management.
Rule Management is in charge of automation and deployment among systems, and automation is performed by executing the one or more of the following nine Rule types:
Event
Blueprint
Independent
Form
Dashboard
Pipeline
Report
Webservice
Workflow
Event
These are triggers that are activated based on a wide array of possible actions performed on the system. These may affect Topics or other Resources (also sometimes known as CIs), such as servers, User IDs, agents, middleware (such as JBoss or Apache), cloud instances, mainframe nodes etc. They may also entail changes to files (creation, deletion etc.), Jobs (creation, cancellation, approval etc.), such as changing of a Topic’s status on execution of a Job.
A simple illustration of using Events is the changing of a Topic’s status on execution of a Job, using a special change topic status Rule. The rationale here is that, when a Job is launched by a User, its Status cannot be changed by the Pipeline Rule (we will come to Pipeline Rules later on) until after the Rule has run. By using event.topic.change_status, we can change the Status to one that does not permit Users to launch a Job using the same Topic while the current Job is being completed. This is done by setting Event Type to Pre Online, thus blocking the Topic before the Job is launched.
Blueprint
Blueprints are Rules that enable modelling of systems and Environments on the basis of variables which are grouped/conditioned by Environment.
Grouping variables in this way streamlines the configuration process, which would otherwise have to be performed manually e.g. when setting up a Project.
Blueprints can then be specified within Natures via the Blueprint combo (see Natures). This enables Blueprints and their Variables, along with any servers (and their configuration), file paths etc. to be passed easily to Projects, Environment Templates etc.
Independent Rule
An Independent Rule is one that is meant to be either included in another Rule e.g. Pipeline Rules (see Pipeline Rule), or used in conjunction with another entity in [the software], such as the Scheduler for setting up the Rule to be run at certain times.
Independent rules are used for anything that does not justify having a rule type of its own, including housekeeping tasks such as periodic log deletion, regression testing, and modularization in order to reduce complexity of Pipeline Rules.
Form Rule
Form Rules provide the necessary fields (text fields, combos, revision boxes, checkboxes etc.) for configuring settings to be associated with Categories. They serve as templates for passing Form information to Topics. When creating Topics, information and essential elements of the Job to be run may be selected in accordance with the Form Rule selected in the Category e.g. git branches containing changes may be passed to a Changeset Topic via a revision box.
Dashboard Rule
Dashboard Rules make it possible to add, edit or remove components in Dashboards (see Boards), which in turn allow adding of calendars, tables showing Topics that are in a specific state, project graphs etc. The Rule can also specify what the User is able to see, on the basis of the Role assigned to said User.
Pipeline Rule
Deployment in [the software] is performed by means of Pipeline-type Rules. This type of Rule contains five logical steps by default, the first two of which, CHECK and INIT, are run by [the software] and are used to lay any necessary groundwork for the deployment Job, such as managing connectivity issues, permissions etc., and it is here that the necessary directory structure is created.
The remaining three steps, PRE, RUN and POST, on the other hand are executed by a service known as a daemon which we will look at in the chapter on Usage. Here, essential Job items and Variables are loaded ahead of time in the PRE step, in preparation for scheduled deployment of the RUN step, which may or may not complete correctly. The final step, POST, runs regardless, and is typically used to change a Topic’s Status in response to whether the Job ran successfully or not.
Report Rule
Report Rules in [the software] allow Users to create personalized grids for displaying Topic -related information according to its relevance, including options and queries, such as layout, permissions, as well as queries, and filtering of information to be displayed.
Webservice Rule
In [the software], a Webservice is a type of Rule that can be called from outside [the software], either from the command line, or from other applications and services. As a basic example, we can create a Topic from outside [the software] by calling a Rule that creates said Topic. For security reasons, Webservice Rule should be configured to require authentication, which in turn requires that an API key be set (see User Preferences in the chapter on Usage). This identifies the user without having to send the password, and is required when running the Rule from a outside wherever authentication is required. A Webservice Rule may be configured to call other Rules within [the software], and is as powerful as the Rule(s) it invokes. Typical uses may include updating of information on activation of a secondary backup system (should the default system fail), approval via email of a change in Topic Status, or synchronization of [the software] with external services (and corresponding information updates) in response to an event or change in Status in the external service.
Workflow Rule
This allows creation of a workflow using rules. Whilst most Topic Categories only require a simple Topic workflow, rule workflows should be used to construct complex decision transitions where conditions are involved. A typical example might be a field-dependent transition: supposing a certain value is set in a combo (e.g. "urgent"), then a transition might be correspondingly skipped (e.g. "promote to QA"). This could also be in response to an event, even an external one, where webservices are used to determine where or how to promote the Topic. Other examples include project-specific workflows, as well as field content checks (checking that a given field has been filled out before allowing promotion to take place). Of particular value is reusability of workflows, as a single workflow rule may be reused in many different topic categories. The Rule is selected in the Category configuration, and overrides any static workflow that may have been defined.
Spanish to English: INE Electronic Office General field: Tech/Engineering Detailed field: Internet, e-Commerce
Source text - Spanish Está usted en Sede Electrónica / Ayuda / Guía de utilización de la Sede
La guía de utilización de la Sede Electrónica del INE se ha diseñado para facilitar la localización de la información y el manejo de las opciones disponibles; no obstante, si encuentra cualquier dificultad en la navegación por la Sede, no dude en utilizar el Formulario de correo para comunicarnos sus preguntas. En esta guía encontrará los siguientes apartados:
1.Estructura de la navegación
2.Accesibilidad
3.Recomendaciones técnicas
4.Política lingüística
Se incluye en este apartado una descripción de los diferentes elementos que encontrará en cada una de las páginas de la Sede.
1.1. Cabecera de navegación
La cabecera se mantiene fija en todas las páginas de la Sede de forma que desde cualquier ubicación se pueda hacer uso de las utilidades. La cabecera se compone de:
Logotipo del INE: al pinchar sobre él se accede a la página de inicio del Instituto Nacional de Estadística . La página se mostrará en una ventana independiente.
Logotipo de administración electrónica: al pinchar sobre él se accede a la página del Ministerio. La página se mostrará en una ventana independiente.
Botonera de opciones: compuesta por los siguientes botones:
cambia el tamaño de los textos. La letra más grande aumenta el tamaño, la más pequeña lo disminuye y la intermedia lo restaura a su tamaño inicial. También puede hacer uso de las opciones de su navegador para cambiar el tamaño de la letra.
muestra el mapa de la web.
muestra el calendario de días inhábiles.
Menús desplegables: permiten navegar por todo el contenido de la Sede deslizando el cursor por el desplegable y posicionándolo sobre el tema y/o subtema. Pinchando directamente sobre la pestaña de la que nace el desplegable, se accede a una página con todas las opciones de ese apartado. Los menús desplegables tienen el siguiente contenido:
Inicio: conduce a la página de inicio de la Sede.
Trámites: contiene la lista de procedimientos y trámites incluidos en la Sede. Pulsando en cualquiera de las opciones se accede a la ficha descriptiva del procedimiento o trámite, donde puede conocer los requisitos necesarios y acceder al procedimiento y ayudas básicas para su correcta tramitación.
Normativa: incluye la legislación que rige tanto el funcionamiento de la Sede como de los diferentes procedimientos y trámites. Permite acceder a cada norma pinchando en el enlace que se incorpora.
Utilidades: incluye el calendario de días inhábiles y los certificados electrónicos publicados en la Sede electrónica del INE.
Ayuda: agrupa diferentes opciones que le facilitarán el manejo de la Sede.
Selección de idiomas: al elegir un idioma de la lista, cambia la página en la que se encuentra a la versión en ese idioma. Si la página no estuviera disponible en el idioma seleccionado, por defecto mostrará la página en español.
Buscador: escribiendo una palabra o palabras y pulsando el botón Buscar se mostrará la relación de páginas de la Sede que incluyen el término buscado.
1.2. Barra de estado
Rastro de migas: la página en la que nos encontramos viene identificada en la parte superior por el texto Está usted en Sede Electrónica seguido del apartado, subapartado, sección,.. en que está ubicada. Pinchando en cualquiera de los textos que aparecen, se accederá a esa página.
Fecha/hora: se muestra la hora oficial. El reloj se actualiza de forma automática cada minuto y cuando se solicita una nueva página o se refresca la página presentada.
1.3. Pie de página
Es común a todas la páginas de la Sede. Contiene información referente a la ubicación de la Sede y acceso directo a algunas opciones.
2.
Accesibilidad
La sede electrónica del INE ha sido diseñada ajustándose a los requerimientos de accesibilidad recogidos en la norma UNE 139803:2012 (prioridad 2).
Por otra parte, en la navegación por la Sede se indican enlaces que acceden a páginas ajenas a la misma y cuyos contenidos pueden no cumplir las mismas pautas de accesibilidad.
Si considera que alguno de los contenidos presentados no es accesible y tiene algún problema para su visualización, puede comunicarse con nosotros a través del Formulario de correo .
Para acceder a los servicios electrónicos le puede ser requerido estar en posesión de alguno de los certificados que se recogen en el apartado Certificado y firma electrónicos .
4.
Política lingüística
Los contenidos de la Sede Electrónica se presentan en todas las lenguas cooficiales y además en lengua inglesa. Sin embargo, en la navegación por la Sede se indican enlaces que acceden a páginas ajenas a la misma y cuyos contenidos pueden no estar disponibles en las distintas lenguas.
Translation - English You are in Electronic Office / Help / Electronic Office user guide
The user guide of the Electronic Office of the INE has been designed for ease of access to information and use of the available options; nevertheless, should you encounter any difficulty browsing the Headquarters,please do not hesitate to use the Email form in order to address your queries to us. The following sections are to be found in this guide:
1.Navigation structure
2.Accessibility
3.Technical recommendations
4.Language policy
This section includes a description of the different elements to be found in each page of the Electronic Office.
1.1. Navigation bar
The navigation bar is static on all pages of the Electronic Office, so that its features may be accessed from anywhere on the site. The bar is comprised of:
INE logo: by clicking on it, one accesses the homepage of the National Statistics Institute . The page is shown in a separate window.
Electronic administration logo: by clicking on it, one accesses the homepage of the Ministry. The page is shown in a separate window.
Options panel: composed of the following options:
change the size of the texts. The largest letter increases the size, the smallest letter decreases the size and the medium-sized letter restores it to its original size. One may also use the options of the navigator to change the font size.
show the map of the website.
show the calendar of non-working days.
Drop-down menus: these allow for navigating all of the content of the Headquarters, moving the cursor on the drop-down menu, and placing it over the topic and/or subtopic. A page can be accessed, containing all of the options in that section, by clicking directly on the main tab of the drop-down menu. The content in drop-down menus is as follows:
Home: this leads to the homepage of the Headquarters.
Paperwork: this contains the list of procedures and paperwork included in the Elecgtronic Office. By clicking on any of the options, we access the descriptive file of the procedure or paperwork, where it is possible to ascertain the necessary requirements, and access the procedure and basic help for its proper undertaking.
Regulations: this includes the legislation that governs the functioning of both the Electronic Office and the different procedures and paperwork. It allows for accessing each regulation by clicking on the incorporated link.
Tools: this includes the calendar of non-working days and electronic certificates published in the electronic headquarters of the INE.
Help: this groups different options which will enable browsing the Electronic Office.
Choice of language: on choosing a language from the list, change the page in which the version of that language is found. If the page is not available in the selected language, by default, the page will be shown in Spanish.
Search engine: by writing a word or words and clicking on the Search icon, this will show the listing of pages of the Headquarters that include the term sought.
1.2. Status bar
Breadcrumb trail: the current page is identified at the top by the text, You are in the Electronic Office, followed by the section, subsection, etc. in which it is located. By clicking on any of the texts that appear, one may access that page.
Date/hour: the official hour is shown. The clock is updated automatically every minute, as well as when a new page is requested, or the presented page is refreshed.
1.3. Footer
This is common to all of the pages of the Headquarters. It contains information regarding the location of the Electronic Office, and direct access to some options.
2.
Accessibility
The Electronic Office of the INE have been designed, adjusting to the accessibility requirements in UNE standard 139803:2012 (priority 2).
In turn, in browsing the Electronic Office, links are indicated that access unrelated websites whose content may not comply with the same accessibility guidelines.
If you consider that any of the content presented is not accessible, and have any difficulty in viewing it, you may communicate with us by using the Email form .
In order to access the electronic services, you may be required to be in possession of one of the certificates included in the section Electronic Certificate and Sign .
4.
Language policy
The content of the Electronic Office is presented in all jointly-official languages, as well as in English. However, when browsing the Office, there are links to external sites, and the contents of these may not be available in other languages.
German to English: protel SEO software General field: Tech/Engineering Detailed field: Internet, e-Commerce
Source text - German SEO für den Menschen, nicht für die Maschine
29. April 2013
0
0
inShare.
Wer weiß schon, wie Suchmaschinen funktionieren? Jeremy Armes, Marketingleiter der protel hotelsoftware GmbH, hat einen besseren Vorschlag: Denken Sie nicht an die Maschine, konzentrieren Sie sich auf den Menschen! Diese Idee stellte er im Adina Apartment Hotel Hamburg Michel Interessierten aus der Hotelbranche vor. Im Austausch miteinander entstanden auf der HSMA-Veranstaltung „SEO ist tot! Lang lebe SEO!“ neue Impulse, die bei der alltäglichen Arbeit direkt nutzbar sind.
Jeremy Armes sprach mit Branchen-vertretern über effektive SEO-Strategien
Vergessen Sie die Maschine! Der Lösungsvorschlag ist gleichzeitig eine Herausforderung. Wenn die Hotel-Website sich an die Menschen richten soll, ist die wichtigste Frage: „Wer ist meine Zielgruppe?“. Die Kunst liegt darin, als Hotel die gleiche Sprache wie die eigene Zielgruppe zu sprechen, damit die Gäste Lust haben, mehr über das Hotel und seine Angebote zu erfahren. Dann ist es nur noch ein kleiner Schritt bis zur Buchung. Diese Sprache zu finden und gezielt einzusetzen, ist die Grundlage für erfolgreiches SEO.
Eine Ansammlung von vermeintlich relevanten Suchbegriffen im Text ist schnell erstellt, überzeugt aber wenig. Verständliche Texte und der gezielte Einsatz von Fotos, Videos und Social Media optimieren die Hotel-Website effektiv. Jeremy Armes erklärt ganz offen: „Nur harte Arbeit und Kreativität führen zum Erfolg!“ Er kennt die Wünsche der Hoteliers nach mehr Direktbuchungen und Gutscheinverkäufen über die eigene Website und weiß daher auch, dass sich der Einsatz für die Hoteliers auszahlt. Wichtiger als einzelne Buchungen ist die langfristige Gästebindung. Wenn die Gäste sich angesprochen und verstanden fühlen und durch passende Online-Angebote ihren Aufenthalt sogar selbst mitgestalten können, werden sie den Service des Hotels bei nächster Gelegenheit gerne wieder nutzen.
Die HSMA-Veranstaltung „SEO ist tot! Lang lebe SEO!“ war eine von vielen Gelegenheiten, die protel für einen direkten Austausch mit anderen Vertretern der Hotelbranche nutzt. Eigenes Wissen mit einer Präsentation zu SEO zu teilen, war nur ein Teil der Veranstaltung. Viele positive Impulse entstehen in den anschließenden Gesprächen. „Es wäre eine gute Idee, gleich mit Jeremys SEO-Check up zu beginnen“, erklärt Birgit Groß von HotelNetSolutions nach der Veranstaltung. Die Aussicht, mit neuen SEO-Strategien eine Bereicherung für Website-Nutzer und -Anbieter zu schaffen, war ein zusätzlicher Anreiz, die Ideen sofort in die Tat umzusetzen.
Über die Hospitality Sales und Marketing Association
Die HSMA (Hospitality Sales und Marketing Association) Deutschland e.V. ist der Verband der Sales- und Marketingfachkräfte in Hotellerie und Tourismus. Sie bildet das Netzwerk und den Wissenspool zu allen relevanten Sales & Marketing Themen der Hospitality Branche. Neben einer Vielzahl von fortbildenden Veranstaltungen zu aktuellen Branchenthemen, schätzen die Mitglieder der HSMA vor allem das hochkarätige Netzwerk und den direkten Kontakt untereinander, der in der Hospitalitybranche unabdingbar ist.
Translation - English SEO for humans, not for machines
April 29, 2013
0
0
inShare.
Who knows how search engines work? Jeremy Armes, Head of Marketing at protel hotelsoftware GmbH, has a better proposal: forget about machines, think more in terms of humans! He presented this idea at the Adina Apartment Hotel Hamburg Michel to interested parties from the hotel industry. The discussion following his show at the HSMA “SEO is dead! Long live SEO!” gave a fresh boost to the day-to-day SEO work in a hotel.
Jeremy Armes discusses effective SEO strategies with industry representatives
Forget machines! The proposed solution represents a challenge at the same time. If the hotel website is to address humans, the most important question is: “who is my target group?“ The trick is for the hotel to speak the same language as the actual target group, so that guests wish to learn more about the hotel and its offers—from there, it is a rather small step to the actual reservation. Pinpointing this language and using it in a selective way is the basis for successful SEO.
A collection of supposedly relevant search words in the text can be composed in next to no time, but is not very convincing on its own. In fact, the keys to an effective optimisation of the hotel website are well written and easily comprehensible texts and the deliberate use of photos, videos and social media. Jeremy Armes is unequivocal in stating that “the path to success is through hard work and creativity alone!” He is aware that hoteliers always are aiming at more direct bookings and coupon sales through their own website, and he is absolutely positive that smart and skilful SEO will be extremely rewarding in this respect. In the long term, guest loyalty is more important than single reservations. If guests feel that they are being addressed and understood, as well as even being able to play a hand themselves in shaping their stay through suitable online offers, they will remember this great service—and happily use it again during their next stay.
The HSMA event “SEO is dead! Long live SEO!” was one of many opportunities capitalised on by protel in order to engage in direct discussions with other representatives from the hotel industry. Imparting their own knowledge with a presentation on SEO was only one part of the event. A good many positive stimuli came to light in the subsequent discussions. “It would be a good idea to start directly with Jeremy’s SEO check“, explains Birgit Groß from HotelNetSolutions after the meeting. For her, as for many other participants, the prospect of enriching their site’s user experience through new SEO strategies was an increased incentive to get down to action immediately.
About the Hospitality Sales and Marketing Association
The HSMA (Hospitality Sales and Marketing Association) Deutschland e.V. is the association for sales and marketing staff in the hotel and tourism industry. It forms the network and knowledge base regarding all relevant sales and marketing topics in the hospitality industry. Apart from an array of ongoing training events regarding current industry topics, members of the HSMA value above all the first-class network and direct contact among themselves, which is indispensable in the hospitality industry.
More
Less
Translation education
Master's degree - Leeds University
Experience
Years of experience: 19. Registered at ProZ.com: Feb 2006.
Spanish to English (University of Leeds) Portuguese to English (University of Leeds) German to English (Goethe Institut)
Memberships
N/A
Software
FSMNLP, UltraEdit, XML, XMLSpy, XSLT, Trados Studio
Bio
I am an experienced translator and have worked both freelance and in-house. My background encompasses a wide array of projects, such as (technical) translation, lexicography (Cambridge University Press), electronic dictionaries (OUP, Collins, Espasa, PONS etc.), ELT editing (Vaughan Systems), CMS, web platform (Linguaserve GBC Server) and E-learning localization (Bizpills OKN), technical writing (mostly DevOps/ALM) and creation and implementation of Machine Translation (MT) solutions. I speak several languages and have over 10 years' translation experience.
I worked for almost seven years as official translator at the Spanish Statistics Institute (INE).
In my most recent in-house position, I translated and proofread texts covering a wide range of topics, including marketing, fashion, museums, news items, legal, software localization and technical manuals for a highly prestigious end client portfolio, including El Corte Inglés, Inditex (Zara, Stradivarius, Pull&Bear,
Oysho, Massimo Dutti etc.), SEGITTUR, the Spanish Ministry of Education, Culture and Sport, Barcelona City Council, RTVE, CaixaBank, INECO, Ilunion, and Universidad Europea de Madrid.
I have created and implemented MT using Moses SMT, and have created factored models by interfacing TMX files with MySQL using native PHP XSLT functionality, NLP software and Python libraries.
Technologies I have worked with include:
SDL Trados
XML
XSLT
RegEx
PHP
MySQL
Python
Moses SMT
POS-taggers
Git
Keywords: XSLT, XML, HTML, CSS, PHP, MySQL, programming languages, devops, ALM, Moses. See more.XSLT, XML, HTML, CSS, PHP, MySQL, programming languages, devops, ALM, Moses, SMT, factored, regex, lexicography, dictionaries, IT, computers, web development, electronic publishing, digital publishing, technical, marketing, financial, legal, tourism, general, archaeology, anthropology. See less.
Expertise